Salesforce mandates MFA by default

Thales: ‘Significant change in security culture'

Paid Feature Of all the cybersecurity developments in 2021, a relatively low-key announcement made by software company Salesforce.com (SFDC) in March might eventually turn out to be one of the most significant.

From February 1, 2022 “Salesforce will begin requiring customers to enable multi factor authentication (MFA) in order to access Salesforce products,” read the announcement. From that point onwards, “all internal users who log in to Salesforce products (including partner solutions) through the user interface must use MFA for every login.”

Multifactor authentication has been a recommended setting for most business access for years but never has a major service provider insisted customers use it as a precondition of service. Even Google and Microsoft, both big advocates for MFA, do not implement it by default to access their services.

This change has profound implications: customers unable to implement MFA across their access by the set date can continue to use Salesforce without MFA at their own risk. Salesforce isn’t simply mandating MFA but making the decision not to use it is the customer’s responsibility as part of its terms and conditions.

“What they are doing is delegating this aspect of access security to their customers and saying that they don’t want to be responsible for it,” comments Thales director of product marketing for identity and access management, Danna Bethlehem.

In effect, Salesforce is reformulating the shared responsibility model that normally governs cloud services. This says that the customer has certain responsibilities, while the service provider has others. Changing that for MFA is more than a tweak. Thales statistics suggest that 90 per cent of cyberattacks utilise compromised credentials in some way, which if correct implies that failing to implement MFA on Salesforce is potentially shifting responsibility for almost all cyberattacks involving the service.

“The customers that are out of compliance could be held liable for any breaches that occur. This could be a harbinger of things to come,” says Bethlehem.

It’s tempting to be cynical about this shift but it’s worth looking at the issue from Salesforce’s perspective. The targeting of credentials has increased dramatically in a handful of years and Salesforce is among the top list of targets. And yet the technology to defend accounts has been available for years in the form of MFA authentication apps, hardware tokens, and password-free options, all of which are supported by Salesforce.

The uncomfortable fact is that despite the rising number of account compromises, not enough customers have turned it on across the board. From now on, that policy will be their problem, not Salesforce’s. Undoubtedly, Bethlehem’s belief that others will follow Salesforce’s lead is correct. Within a year or two, mandated MFA could quickly become the norm across many cloud services.

The interesting question is perhaps not how many customers will comply but why more of them haven’t done so already in the face of evidence that MFA works well. Bluntly, why is it necessary to mandate a good idea?

Every user is a target

The Thales Access Management Index found that only around 55 per cent of European IT professionals reported that their organisations had adopted MFA, in line with the global average, with the figure for the UK slightly higher at 64 per cent.

These figures sound moderately encouraging until you read that a lot of this MFA usage relates to traditional remote access/VPN applications and privileged users. For cloud access, only 15 per cent of organisations protected more than 50 per cent of their users.

“In today’s threat environment, every user is a target. Just having an arbitrary authentication footprint in an organisation is going to leave big gaps,” observes Bethlehem. This approach became obsolete years ago even if it has taken Salesforce’s mandate to ram that point home. “When organisations implement MFA for Salesforce they should already have been doing this for all users because all users are targets.”

Of course, telling organisations to implement MFA and that happening are not the same thing which is presumably why Salesforce gave customers 11 months’ notice of the need to comply. Arguably, this isn’t long enough.

Authentication remains complex, starting with the confusing array of options for different use cases. According to Bethlehem, what matters is to stop seeing authentication as something for special occasions and to approach the technology in a more strategic way.

Usually, the issue of implementing MFA strategically is approached either as a technology problem or as a use case problem. The advantage of the first approach is that it is a relatively quick way to get up and running if you’re already invested in MFA and the use cases aren’t complex. For these customers, rolling out Salesforce MFA could be a matter of expanding what they’re already doing.

The second approach is to carry out an audit of the possible use cases, using different methods depending on the user context. This suits organisations that are either not already using MFA widely or have specific requirements, for example the medical or manufacturing sectors where some technologies might be more convenient or compliant than others.

“The main priority for Salesforce customers will be to implement MFA for Salesforce. But they shouldn’t stop there and should ideally do an assessment of which other applications and users they might need to protect this way,” recommends Bethlehem. “We help our customers on this discovery process and will do an assessment of their entire environment.”

Technology choices

The clear message from Salesforce’s MFA FAQ is that some established methods such as SMS texts, phone calls and emails will no longer be good enough to authenticate to their platform, nor will VPN access override this requirement. Technologies such as SMS haven’t been considered secure for several years and emails were never so even though some adopted them as a cheap way to implement the second factor.

That leaves two paths – the basic MFA offered by Salesforce or using a third party provider. This could include a FIDO token supporting WebAuthn and U2F (for example offered by Thales, Google’s Titan or the YubiKey), or proprietary authentication systems such as Apple’s Touch ID/Face ID, or Windows Hello.

This is the good news about today’s MFA environment – there is no shortage of options to choose from. For most organisations, this will mean using the smartphone as the core authenticator, either running an app or using some form of biometrics or FIDO2 WebAuthn. For privileged users, this might be backed up with the gold standard of a FIDO U2F hardware token.

Look a little closer, however, and some caveats appear for the latter option when accessing Salesforce, mainly around browsers. For example, WebAuthn keys aren’t supported in the pre-Chromium versions of Microsoft Edge while U2F is supported only in Google’s Chrome. Similarly, not all U2F tokens support smartphone access seamlessly, or at all.

Authentication everywhere

In Bethlehem’s view, evolving user and security needs will in many cases mean that a bespoke approach is the only option. The USP of an identity and access management specialist such as Thales is that it can integrate any possible combination of hardware and software, including supporting the technologies an organisation has already invested in.

“You have to take into account how to manage everything, especially if you’re mixing hardware with software. You need a good management backend otherwise the management becomes intense,” observes Bethlehem.

In most cases this will mean a mix of hardware and software MFA for different types of user, often where the problems start. “Many vendors don’t offer integrated hardware and merely support it. If a company wants to add additional types of hardware, they will always have to go to another vendor to do that. But in many cases they don’t offer good management support for these technologies.”

A popular solution for cloud applications such as Salesforce is SSO, which puts multiple services behind the front door of a single authentication interface, for example Thales’s own SafeNet Trusted Access. The disadvantage of SSO is that it relies on a single credential, hence the need to use it with MFA, and often assumes that every user can be governed by a single IAM policy. But the minute an organisation must support a lot of different use cases, that requires a more sophisticated approach to policy configuration. Not all SSO services offer this.

“You need a policy engine that will enforce the appropriate level of authentication depending on the context of the user, for example accessing a sensitive application governed by regulation. Our policy engine makes sure that the correct authentication is always applied for that user and application,” says Bethlehem.

“Thales is the only vendor that sells every option in an integrated way, including adaptive authentication, FIDO tokens, OTP tokens, pattern-based authentication, authentication apps, push authentication, all integrated with an access management system.”

Does the Salesforce policy change have wider implications? In Bethlehem’s view, it’s a signal of the need to adopt authentication because it’s the best way to secure their users, not because they are being told to do it. This will bring with it a significant change in security culture. Until now, only remote workers or privileged users were protected with MFA while everyone else made do with passwords or simple but sub-standard options such as SMS. Now there is a case for onboarding everyone.

“Organisations are now embracing remote working for all users as an everyday part of their business operation. Salesforce has reminded them that securing this requires that authentication is no longer a luxury and should be used everywhere.”

Sponsored by Thales.