How to specify an AuthnContextClassRef in a SAML Response

Question

How to specify an AuthnContextClassRef in a SAML Response

BooneTom-7296 95

We have implemented a conditional access policy in Microsoft Entra that enforces multi-factor authentication (MFA). However, after successfully authenticating using secure methods such as a Passkey through Microsoft Authenticator or a Smartcard/Certificate, the SAML response still includes the following:

<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Unspecified</AuthnContextClassRef>

This is causing issues with applications like Salesforce, which require the AuthnContextClassRef to specify a secure authentication method (e.g., MFA, Smartcard, PKI) to validate the authentication and allow authorization. Without this, the authentication is rejected, and access is denied.

Is there a way to manually configure or specify the AuthnContextClassRef in the SAML response to accurately reflect the authentication method used, even if Microsoft Entra does not automatically recognize or report it? If so, what steps or configurations are required to achieve this?

Additional Context

We are using conditional access policies to enforce MFA.
The issue occurs regardless of whether the authentication method is a Passkey, Smartcard, or Certificate.
Applications like Salesforce expect a specific AuthnContextClassRef value to validate secure authentication methods.

Rukmini 43,905 Reputation points Microsoft External Staff Moderator

2026-01-20T12:37:20.3133333+00:00
Hello Boone, Tom,

The SAML cannot be manually configured or overridden using Microsoft Entra ID. It is consistently released as: Urn: Oasisnames: tc:SAML:2.0:ac:classes: Not specified —even when Smartcards, Certificates, Passkeys (FIDO2), or MFA are utilized. This is a known product limitation that cannot be changed using SAML or Conditional Access settings.

Workaround:

Instead of using AuthnContextClassRef, use authentication claims: Enterprise Applications in the Entra Admin Center → Your Application → Single sign-on ->Attributes & Claims

Add a claim: Amr's name Source: user.authenticationmethodsreferences

Set up Salesforce to: When amr includes mfa, fido, or x509, trust MFA. IgnoreAuthnContextClassRef
BooneTom-7296 95 Reputation points

2026-01-20T12:56:07.0066667+00:00

Thank you Rukmini. That is not the answer I would like, but it is an answer I expected. :-(

I sure wish Microsoft would embrace appropriate standards when implementing solutions like SAML/OIDC. They tend to do 80% of something and leave the remaining 20% as a limitation.
Rukmini 43,905 Reputation points Microsoft External Staff Moderator

2026-01-20T13:34:54.5733333+00:00

Boone, Tom Yes I understand, you can raise a feedback here https://feedback.azure.com/d365community/forum/22920db1-ad25-ec11-b6e6-000d3a4f0789
Rukmini 43,905 Reputation points Microsoft External Staff Moderator

2026-01-20T13:35:28.46+00:00

Boone, Tom, Also if any further queries, please do let me know!
Matthew Heinbuch 30 Reputation points

2026-01-20T19:28:19.7833333+00:00

Hi Tom,

I wanted to jump in on this thread as well as I've been researching this topic ahead of the announced changes to Salesforce SSO logins that will require users to authenticate their device if one of a few conditions isn't met.

In our org, we're using SAML for SSO with Salesforce and I wanted to make sure that the AuthnContext header is included in our SAML responses and confirm if a secure authentication method, such as MFA, is being used or not. When I ran a test login through Entra, I could see the AuthnContext header is included but where it seems like our configs differ is our responses show the AuthnContextClassRef as 'password' instead of unspecified. I thought it was odd for the value to be set to password when we have a conditional access policy enforcing MFA for all our users as well, which is what lead me down this rabbit hole. From what I've been able to gather, it isn't possible to manually change this value either so I definitely share your frustration.

I don't really have an answer yet that will really help either of us but maybe someone will come along with a better answer soon. We're hoping the changes don't impact our users too heavily because at worst, it seems to just be an additional verification step and then that device/browser is authenticated for 365 days due to the information being stored in a Salesforce-related cookie.
BooneTom-7296 95 Reputation points

2026-01-20T20:00:01.28+00:00

Thank you Matthew. I am sure there are more than just our two companies who use SSO into Salesforce. Hopefully enough of us will communicate the situation with Salesforce and they'll delay the security enhancement.

I understand why they would like to enforce the more secure Authentication methods, but not all IDPs are communicating the Authentication method properly.
Feldhacker 60 Reputation points

2026-01-21T02:24:20.1766667+00:00

Same as Matthew, we are also seeing "Password" vs Unspecified in the SAML response when using SSO with MFA via mobile app.

<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>

Strange how different customers see different values in a place that cannot be configured or controlled...?
Wyatt Chilton 25 Reputation points

2026-01-21T02:44:10.5533333+00:00

Same as Matthew and Feldhacker we see Password. I joined the salesforce webinar they held today and their response basically was "you will need to reach out to your IdP as we can't answer IdP specific questions" which I think is absolutely insane. From my understanding the header value is controlled by the Service Provider (Salesforce) and their wording on the update is very vague causing more confusion then anything. If you take their wording to heart (including the slides they had in the webinar) what it seems like they're saying is you just need to ensure that the AuthnContext header and it's value are accepted in the SAML flow.
RobOinPA 45 Reputation points

2026-01-23T14:02:52.8966667+00:00

The option to Add a claim: Amr's name Source: user.authenticationmethodsreferences doesn't work, as the source is not visible via SAML. Frustrating.
Narula, Tarun 10 Reputation points

2026-01-26T11:38:34.8866667+00:00

Jumping in as we’re facing the same limitation across 11 different Entra ID tenants. We’re using SAML SSO enforcing MFA (including Microsoft Authenticator), yet the SAML response still returns Password for AuthnContextClassRef, with no supported way to configure or override this in Entra.

At this point, we’re mainly trying to understand:

Has anyone successfully resolved this in Entra without relying on SP-side workarounds?

Or is everyone effectively forced to ignore AuthnContextClassRef and depend on alternative claims (where supported)?
Andy O 0 Reputation points

2026-01-26T23:20:27.1+00:00

Salesforce released some updated guidance today (1/26/26) that may be helpful for those in this thread.
https://help.salesforce.com/s/articleView?id=005237070&type=1

AMR is likely the path forward for many IdPs
Feldhacker 60 Reputation points

2026-01-27T00:49:25.35+00:00

Even with Salesforce relaxing the AuthnContext requirement and relying on AMR there's still a problem because in the "authnmethodsreferences" attribute Entra is passing the AttributeValue "http://schemas.microsoft.com/claims/multipleauthn", whereas Salesforce will only recognize values specified by the RFC spec which is "mfa" and NOT "multipleauthn". Even the relaxed substring matching that Salesforce is doing is still insufficient.
Ted Joffs 5 Reputation points

2026-01-27T14:34:24.31+00:00

Feedback Requested - Please Upvote if you have this issue.
https://feedback.azure.com/d365community/idea/c18d0909-8cfb-f011-bb46-7c1e52be2cc8
Thomas Frederiksen 16 Reputation points

2026-01-27T15:13:39.15+00:00

We have the same issue.

@Rukmini I tried your suggestion, but in our Entra ID there is no attribute source by the name "user.authenticationmethodsreferences"

The way I understand the Salesforce page on the change, it might be possible to simply add a "AMR" claim and set the value statically to "mfa".

But as @Feldhacker points out - question is how Salesforce treat the SAML response when they get conflicting values in "authmethodsreferences", "AMR" and "AuthnContext". Will they bypass device activation if at least one of these methods indicate a secure method of authenticating?

If this works - then it is of course only a workaround as it will always send "mfa" as the value even if the authentication method in Entra was insecure.
RobOinPA 45 Reputation points

2026-01-27T15:18:50.2533333+00:00

@Thomas Frederiksen exactly, SAML doesn't present user.authenticationmethodsreferences as an attribute source. I'm hoping this will work:

add a "AMR" claim and set the value statically to "mfa"
Feldhacker 60 Reputation points

2026-01-27T15:36:36.87+00:00

I suspect Salesforce would not be supportive of a solution that allows customers to just "fake" / assert that MFA is being used when it is not. The AuthnContext element cannot be spoofed by customers, neither can the "authnmethodsreferences" attribute (I tried, says it's a "restricted"). We're at the mercy of Microsoft providing some manner of reliable, trustworthy claims.
dkSF-8532 0 Reputation points

2026-01-27T16:25:56.31+00:00

We are also affected and looking forward to find a solution how either AuthnContext or AMR can be transmitted from Entra to Salesforce during the SAML response in an acceptable way.
At least I'm in the process of postponing the SF change for our org. SF Support seems to aknowledge this being an issue for Microsoft Entra IdP customers.
Jared Buschkopf 256 Reputation points

2026-01-27T18:16:17.37+00:00

Like @Feldhacker and others are saying I'm also seeing that the updated guidance still shows values for SAML AMR that don't actually align with what Microsoft Entra ID puts in the SAML responses in the authnmethodsreferences attribute. Actually I noticed they removed x509 from the list of accepted values which makes it even harder for us to be compatible.

I also agree that we shouldn't be putting static values in our SAML responses that might not reflect actual authentication methods used. Even if the static value matches your MFA/authentication method policies now, if those change or there is a misconfiguration it may not be accurate as far as what the user actually used during their sign-in. If you have some users using authentication method #1 and some using authentication method #2, or the ability to choose different methods, what static value would be appropriate?

Also, with the 1/26 updates to the Salesforce article ( https://help.salesforce.com/s/articleView?id=005237070&type=1), Salesforce now says that on 2/17 they're changing the SAML requests sent from Salesforce to the IDP to ask for specific authentication methods to be used.

While it is encouraging that Salesforce is trying to adapt, without understanding how exactly they are planning on doing this (what exactly will the SAML request look like going forward?) and whether or not Salesforce has confirmed that their changes are compatible with Entra ID, I'm a bit concerned about possible sign in errors like this one which my org has seen before when service providers try to request certain authentication methods:

https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/app-integration/error-code-aadsts75011-auth-method-mismatch

Salesforce says they're going to ask "for specific Authentication Method References (AMR) in the SAML AuthnRequest sent to your Identity Provider". According to the Microsoft SAML documentation (https://learn.microsoft.com/en-us/entra/identity-platform/single-sign-on-saml-protocol?source=recommendations#requestedauthncontext), Entra ID will accept a "RequestedAuthnContext" in the request from the Service Provider but I'm curious what values Salesforce will be using because the AMR values in the Salesforce article do not align with the accepted RequestedAuthnContext values in the Microsoft docs. Maybe since the updated Salesforce article seems to be saying AMR and AuthnContext values can be used interchangeably, they will send both sets of accepted values in the request. However, it's not very clear on this for the SAML request, and it certainly doesn't specify whether they would put them in the RequestedAuthnContext element or some other AMR thing of their own choosing.

We've submitted tickets on both Salesforce and Microsoft sides last week and are keeping them open. We were at least granted a 60 day extension from Salesforce on the application of these changes to our org.

I've also upvoted 2 feedback posts here as others have been recommending:

https://feedback.azure.com/d365community/idea/c6a81a1c-08f6-f011-92b8-6045bdb235d9

https://feedback.azure.com/d365community/idea/c18d0909-8cfb-f011-bb46-7c1e52be2cc8
Moin Shah Mohammed 0 Reputation points

2026-01-28T18:11:28.4433333+00:00

If anyone found a solution, please put it here.
We're in the same boat
Shalane Frost (NonUS) 0 Reputation points

2026-01-28T19:59:13.7866667+00:00

I was told by Salesforce support this morning to (in different words) use the fake it method- meaning add a claim called AMR with a static value of mfa.
I requested an extension for our org. That would be my recommendation to others at this point.
Moin Shah Mohammed 0 Reputation points

2026-01-29T06:11:32.6366667+00:00

@Shalane Frost (NonUS)

Could you share the instructions how you're doing this? In Entra or Salesforce?
In Entra, I didn't see an option to add custom claim.
Thomas Frederiksen 16 Reputation points

2026-01-29T08:25:58.8533333+00:00

@Moin Shah Mohammed It depends if you are using OIDC or SAML with Salesforce.
If you are using OIDC then you can't modify it (to my knowledge).

If you are using SAML then you can add all the custom claims you want in Entra ID. Go to the Enterprise Application, Single sign-on, Edit Attributes & Claims, Add new claim.

As mentioned previously, we don't know for certain if this will work as a workaround, as Entra will send conflicting claims ("authmethodsreferences", "AMR" and "AuthnContext").
It will also decrease security as you are in effect telling Salesforce that all your users are authenticated securely with mfa, even if they are not.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Patrick 5 Reputation points

2026-01-30T22:21:21.39+00:00
As I understand it. you need to:

Go to your Enterprise Applications > Single Sign-on page

Click on the Attributes and Claims

Click "+ Add new claim"

Name: amr

Source: Attribute

Set the value manually as mfa.

It will accept it even if it's not a supported attribute. it will ship it as a literal value.

I have no way to test this until the 3rd, but my SAMLRESPONSE now adds

</Attribute> <Attribute Name="amr"> <AttributeValue>mfa</AttributeValue> </Attribute>

To the <AttributeStatement> section.

From what I understand this is what is required. I will update when I see if this works.
Andrelys 0 Reputation points

2026-02-03T16:40:48.12+00:00

Hello Patrick,

Did it work? We currently have a case to fix ours, but Microsoft is not even sure this will work.

Thank you.
Herron, Scott 10 Reputation points

2026-02-03T17:25:41.9566667+00:00

Salesforce has reported back to our ticket on this that they would be adding multipleauthn February 17th.

Thank you for contacting Salesforce Support regarding the Microsoft Entra ID "multipleauthn" authentication context compatibility with Salesforce's MFA enforcement and device activation requirements.

I have excellent news! Your request has perfect timing, as Salesforce has already recognized this as a known compatibility gap and has developed a solution.

Salesforce is releasing an update on February 17, 2026 that will specifically address the Microsoft Entra ID "multipleauthn" compatibility issue.

What's Changing:

Salesforce will update the SAML authentication engine to recognize and accept the "multipleauthn" value within the authnmethodsreferences attribute (in the Microsoft-specific namespace).

When this value is detected, Salesforce will categorize the session as "High Assurance," which satisfies the Secure Authentication requirement and bypasses Device Activation prompts.

This means your users who authenticate via Entra ID with MFA will no longer encounter device activation requirements after February 17th.
Eric Vuong 0 Reputation points

2026-02-17T05:10:11.3733333+00:00

Any updates?
Wyatt Chilton 25 Reputation points

2026-02-17T12:18:58.2666667+00:00

So we had salesforce delay the update being applied to our Prod instance until March 4th so we could test. We did verify with salesforce support that the update was applied to our multiple dev instances where the same SSO setup is configured. The SSO flow works just like it did before, we changed nothing and didn't add a custom "MFA" claim. We also inspected the SAML response to see if anything changed and it was exactly the same (showed password under AuthnContext). So TLDR thank you salesforce for poor communication and the nothingburger!
Feldhacker 60 Reputation points

2026-02-18T15:54:37.9066667+00:00

MFA is a big umbrella with numerous mechanisms implemented and supported by different companies (SMS, email, TOTP, hardware keys, etc.). As groups like NIST have identified specific mechanisms as more/less secure than others, the MFA details matter.

Salesforce started out with goals of wanting to be very surgical with identifying the exact MFA mechanisms that are considered "secure", and enforce additional security controls (device activation) when less-secure MFA mechanisms were used, including no MFA at all. For customers using SSO, the IdP needs to provide sufficient details for Salesforce to respond appropriately, but the SAML responses from Entra ID lack adequate detail.

This specific situation was "resolved" because the number of Microsoft customers was large enough that Salesforce relented and backed off their goal of trying to enforce strong MFA mechanisms. Instead, Salesforce chose to provide special accommodations (relaxed security requirements) for Microsoft customers by choosing to accept a generic "multipleauthn" response and treat it as secure always, no surgical distinction between MFA mechanisms possible. I would not consider forcing a service provider to downgrade its security requirements to be a win. Salesforce may be among the first SaaS companies to push for improved MFA security, but certainly it won’t be the last.
Shivesh Rai 0 Reputation points

2026-02-25T07:12:08.4433333+00:00

@Herron, Scott So does it mean that now we need to create a custom claim "amr" and set its value to "multipleauthn" ?
Sorry if that sounds silly, but right now I am very desperate for a solution that works.

Also, do we need to make any change at Salesforce's end to accomodate this "amr" claim? We have simply setup a SSO configuration, and there is no Login Flow implemented to behave in a specific way in response to a SAML authentication.

Has anyone been able to implement this properly? If yes, please share the detailed steps on how to configure this on the Entra IDs end, as well Salesforce's end.
Jared Buschkopf 256 Reputation points

2026-02-25T15:33:47.4266667+00:00
@Shivesh Rai

I don't know the full situation or requirements for your organization or what your environment is like, but I can tell you that my organization has done the following before these Salesforce changes were ever announced:

Configured Entra ID and Salesforce for SAML SSO using the instructions provided by Microsoft: https://learn.microsoft.com/en-us/entra/identity/saas-apps/salesforce-tutorial

Configured Entra ID to require MFA for our users:

On the Entra ID side:

We have set up Authentication Method policies to allow users to use the authentication methods that make sense for us. These are configured in such a way that we're sure our Salesforce users will be using strong enough methods to meet Salesforce requirements (you may find that it's a good idea for those to be used on other apps and for other users in your org too). See Microsoft docs in this area: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods-manage

We have set up a Conditional Access Policy requiring the users to do MFA (ensuring this applies to the Salesforce app and our Salesforce users though likely you'll want it to target other apps and users in your org too). See Microsoft docs like this one: https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-azure-mfa

For a brief time our org also used authentication strengths to enforce certain authentication methods through conditional access policies, but we no longer do as we can do what we need to in a simpler way through authentication method policies and conditional access. That being said it might be a useful option for your org depending on your situation: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths

With all of the above configurations for SSO + authentication methods + conditional access policies, we did not have to do anything special on either the Salesforce or the Entra ID side to prevent the extra device activation prompts in Salesforce.

Entra ID automatically emits this attribute in the AttributeStatement of the SAML response:

<Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences">

and inside that Attribute element is this AttributeValue:

<AttributeValue>http://schemas.microsoft.com/claims/multipleauthn</AttributeValue>

Per current Salesforce documentation this will be picked up by Salesforce and accepted as strong authentication and the device activation prompt will be bypassed.

Note: these Salesforce changes for the extra device activation prompt have been postponed for our production org, but Salesforce confirmed they have been applied to our sandbox org. In our subsequent testing in our sandbox, we have not had any users get the extra Salesforce device activation prompt on top of our strong SSO + MFA through Entra ID. I am hopeful things will not be any different when our extension expires and Salesforce applies the changes to our production org.

Hopefully that helps.

3 answers

Your answer

Rukmini 43,905 Reputation points Microsoft External Staff Moderator

2026-01-20T12:37:20.3133333+00:00

Hello Boone, Tom,

The SAML cannot be manually configured or overridden using Microsoft Entra ID. It is consistently released as: Urn: Oasisnames: tc:SAML:2.0:ac:classes: Not specified —even when Smartcards, Certificates, Passkeys (FIDO2), or MFA are utilized. This is a known product limitation that cannot be changed using SAML or Conditional Access settings.

Workaround:

Instead of using AuthnContextClassRef, use authentication claims: Enterprise Applications in the Entra Admin Center → Your Application → Single sign-on ->Attributes & Claims

Add a claim: Amr's name Source: user.authenticationmethodsreferences

Set up Salesforce to: When amr includes mfa, fido, or x509, trust MFA. IgnoreAuthnContextClassRef
BooneTom-7296 95 Reputation points

2026-01-20T12:56:07.0066667+00:00

Thank you Rukmini. That is not the answer I would like, but it is an answer I expected. :-(

I sure wish Microsoft would embrace appropriate standards when implementing solutions like SAML/OIDC. They tend to do 80% of something and leave the remaining 20% as a limitation.
Rukmini 43,905 Reputation points Microsoft External Staff Moderator

2026-01-20T13:34:54.5733333+00:00

Boone, Tom Yes I understand, you can raise a feedback here https://feedback.azure.com/d365community/forum/22920db1-ad25-ec11-b6e6-000d3a4f0789
Rukmini 43,905 Reputation points Microsoft External Staff Moderator

2026-01-20T13:35:28.46+00:00

Boone, Tom, Also if any further queries, please do let me know!
Matthew Heinbuch 30 Reputation points

2026-01-20T19:28:19.7833333+00:00

Hi Tom,

I wanted to jump in on this thread as well as I've been researching this topic ahead of the announced changes to Salesforce SSO logins that will require users to authenticate their device if one of a few conditions isn't met.

In our org, we're using SAML for SSO with Salesforce and I wanted to make sure that the AuthnContext header is included in our SAML responses and confirm if a secure authentication method, such as MFA, is being used or not. When I ran a test login through Entra, I could see the AuthnContext header is included but where it seems like our configs differ is our responses show the AuthnContextClassRef as 'password' instead of unspecified. I thought it was odd for the value to be set to password when we have a conditional access policy enforcing MFA for all our users as well, which is what lead me down this rabbit hole. From what I've been able to gather, it isn't possible to manually change this value either so I definitely share your frustration.

I don't really have an answer yet that will really help either of us but maybe someone will come along with a better answer soon. We're hoping the changes don't impact our users too heavily because at worst, it seems to just be an additional verification step and then that device/browser is authenticated for 365 days due to the information being stored in a Salesforce-related cookie.
BooneTom-7296 95 Reputation points

2026-01-20T20:00:01.28+00:00

Thank you Matthew. I am sure there are more than just our two companies who use SSO into Salesforce. Hopefully enough of us will communicate the situation with Salesforce and they'll delay the security enhancement.

I understand why they would like to enforce the more secure Authentication methods, but not all IDPs are communicating the Authentication method properly.
Feldhacker 60 Reputation points

2026-01-21T02:24:20.1766667+00:00

Same as Matthew, we are also seeing "Password" vs Unspecified in the SAML response when using SSO with MFA via mobile app.

<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>

Strange how different customers see different values in a place that cannot be configured or controlled...?
Wyatt Chilton 25 Reputation points

2026-01-21T02:44:10.5533333+00:00

Same as Matthew and Feldhacker we see Password. I joined the salesforce webinar they held today and their response basically was "you will need to reach out to your IdP as we can't answer IdP specific questions" which I think is absolutely insane. From my understanding the header value is controlled by the Service Provider (Salesforce) and their wording on the update is very vague causing more confusion then anything. If you take their wording to heart (including the slides they had in the webinar) what it seems like they're saying is you just need to ensure that the AuthnContext header and it's value are accepted in the SAML flow.
RobOinPA 45 Reputation points

2026-01-23T14:02:52.8966667+00:00

The option to Add a claim: Amr's name Source: user.authenticationmethodsreferences doesn't work, as the source is not visible via SAML. Frustrating.
Narula, Tarun 10 Reputation points

2026-01-26T11:38:34.8866667+00:00

Jumping in as we’re facing the same limitation across 11 different Entra ID tenants. We’re using SAML SSO enforcing MFA (including Microsoft Authenticator), yet the SAML response still returns Password for AuthnContextClassRef, with no supported way to configure or override this in Entra.

At this point, we’re mainly trying to understand:

Has anyone successfully resolved this in Entra without relying on SP-side workarounds?

Or is everyone effectively forced to ignore AuthnContextClassRef and depend on alternative claims (where supported)?
Andy O 0 Reputation points

2026-01-26T23:20:27.1+00:00

Salesforce released some updated guidance today (1/26/26) that may be helpful for those in this thread.
https://help.salesforce.com/s/articleView?id=005237070&type=1

AMR is likely the path forward for many IdPs
Feldhacker 60 Reputation points

2026-01-27T00:49:25.35+00:00

Even with Salesforce relaxing the AuthnContext requirement and relying on AMR there's still a problem because in the "authnmethodsreferences" attribute Entra is passing the AttributeValue "http://schemas.microsoft.com/claims/multipleauthn", whereas Salesforce will only recognize values specified by the RFC spec which is "mfa" and NOT "multipleauthn". Even the relaxed substring matching that Salesforce is doing is still insufficient.
Ted Joffs 5 Reputation points

2026-01-27T14:34:24.31+00:00

Feedback Requested - Please Upvote if you have this issue.
https://feedback.azure.com/d365community/idea/c18d0909-8cfb-f011-bb46-7c1e52be2cc8
Thomas Frederiksen 16 Reputation points

2026-01-27T15:13:39.15+00:00

We have the same issue.

@Rukmini I tried your suggestion, but in our Entra ID there is no attribute source by the name "user.authenticationmethodsreferences"

The way I understand the Salesforce page on the change, it might be possible to simply add a "AMR" claim and set the value statically to "mfa".

But as @Feldhacker points out - question is how Salesforce treat the SAML response when they get conflicting values in "authmethodsreferences", "AMR" and "AuthnContext". Will they bypass device activation if at least one of these methods indicate a secure method of authenticating?

If this works - then it is of course only a workaround as it will always send "mfa" as the value even if the authentication method in Entra was insecure.
RobOinPA 45 Reputation points

2026-01-27T15:18:50.2533333+00:00

@Thomas Frederiksen exactly, SAML doesn't present user.authenticationmethodsreferences as an attribute source. I'm hoping this will work:

add a "AMR" claim and set the value statically to "mfa"
Feldhacker 60 Reputation points

2026-01-27T15:36:36.87+00:00

I suspect Salesforce would not be supportive of a solution that allows customers to just "fake" / assert that MFA is being used when it is not. The AuthnContext element cannot be spoofed by customers, neither can the "authnmethodsreferences" attribute (I tried, says it's a "restricted"). We're at the mercy of Microsoft providing some manner of reliable, trustworthy claims.
dkSF-8532 0 Reputation points

2026-01-27T16:25:56.31+00:00

We are also affected and looking forward to find a solution how either AuthnContext or AMR can be transmitted from Entra to Salesforce during the SAML response in an acceptable way.
At least I'm in the process of postponing the SF change for our org. SF Support seems to aknowledge this being an issue for Microsoft Entra IdP customers.
Moin Shah Mohammed 0 Reputation points

2026-01-28T18:11:28.4433333+00:00

If anyone found a solution, please put it here.
We're in the same boat
Shalane Frost (NonUS) 0 Reputation points

2026-01-28T19:59:13.7866667+00:00

I was told by Salesforce support this morning to (in different words) use the fake it method- meaning add a claim called AMR with a static value of mfa.
I requested an extension for our org. That would be my recommendation to others at this point.
Moin Shah Mohammed 0 Reputation points

2026-01-29T06:11:32.6366667+00:00

@Shalane Frost (NonUS)

Could you share the instructions how you're doing this? In Entra or Salesforce?
In Entra, I didn't see an option to add custom claim.
Thomas Frederiksen 16 Reputation points

2026-01-29T08:25:58.8533333+00:00

@Moin Shah Mohammed It depends if you are using OIDC or SAML with Salesforce.
If you are using OIDC then you can't modify it (to my knowledge).

If you are using SAML then you can add all the custom claims you want in Entra ID. Go to the Enterprise Application, Single sign-on, Edit Attributes & Claims, Add new claim.

As mentioned previously, we don't know for certain if this will work as a workaround, as Entra will send conflicting claims ("authmethodsreferences", "AMR" and "AuthnContext").
It will also decrease security as you are in effect telling Salesforce that all your users are authenticated securely with mfa, even if they are not.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Patrick 5 Reputation points

2026-01-30T22:21:21.39+00:00

As I understand it. you need to:

Go to your Enterprise Applications > Single Sign-on page

Click on the Attributes and Claims

Click "+ Add new claim"

Name: amr

Source: Attribute

Set the value manually as mfa.

It will accept it even if it's not a supported attribute. it will ship it as a literal value.

I have no way to test this until the 3rd, but my SAMLRESPONSE now adds

</Attribute> <Attribute Name="amr"> <AttributeValue>mfa</AttributeValue> </Attribute>

To the <AttributeStatement> section.

From what I understand this is what is required. I will update when I see if this works.
Andrelys 0 Reputation points

2026-02-03T16:40:48.12+00:00

Hello Patrick,

Did it work? We currently have a case to fix ours, but Microsoft is not even sure this will work.

Thank you.
Herron, Scott 10 Reputation points

2026-02-03T17:25:41.9566667+00:00

Salesforce has reported back to our ticket on this that they would be adding multipleauthn February 17th.

Thank you for contacting Salesforce Support regarding the Microsoft Entra ID "multipleauthn" authentication context compatibility with Salesforce's MFA enforcement and device activation requirements.

I have excellent news! Your request has perfect timing, as Salesforce has already recognized this as a known compatibility gap and has developed a solution.

Salesforce is releasing an update on February 17, 2026 that will specifically address the Microsoft Entra ID "multipleauthn" compatibility issue.

What's Changing:

Salesforce will update the SAML authentication engine to recognize and accept the "multipleauthn" value within the authnmethodsreferences attribute (in the Microsoft-specific namespace).

When this value is detected, Salesforce will categorize the session as "High Assurance," which satisfies the Secure Authentication requirement and bypasses Device Activation prompts.

This means your users who authenticate via Entra ID with MFA will no longer encounter device activation requirements after February 17th.
Eric Vuong 0 Reputation points

2026-02-17T05:10:11.3733333+00:00

Any updates?
Wyatt Chilton 25 Reputation points

2026-02-17T12:18:58.2666667+00:00

So we had salesforce delay the update being applied to our Prod instance until March 4th so we could test. We did verify with salesforce support that the update was applied to our multiple dev instances where the same SSO setup is configured. The SSO flow works just like it did before, we changed nothing and didn't add a custom "MFA" claim. We also inspected the SAML response to see if anything changed and it was exactly the same (showed password under AuthnContext). So TLDR thank you salesforce for poor communication and the nothingburger!
Feldhacker 60 Reputation points

2026-02-18T15:54:37.9066667+00:00

MFA is a big umbrella with numerous mechanisms implemented and supported by different companies (SMS, email, TOTP, hardware keys, etc.). As groups like NIST have identified specific mechanisms as more/less secure than others, the MFA details matter.

Salesforce started out with goals of wanting to be very surgical with identifying the exact MFA mechanisms that are considered "secure", and enforce additional security controls (device activation) when less-secure MFA mechanisms were used, including no MFA at all. For customers using SSO, the IdP needs to provide sufficient details for Salesforce to respond appropriately, but the SAML responses from Entra ID lack adequate detail.

This specific situation was "resolved" because the number of Microsoft customers was large enough that Salesforce relented and backed off their goal of trying to enforce strong MFA mechanisms. Instead, Salesforce chose to provide special accommodations (relaxed security requirements) for Microsoft customers by choosing to accept a generic "multipleauthn" response and treat it as secure always, no surgical distinction between MFA mechanisms possible. I would not consider forcing a service provider to downgrade its security requirements to be a win. Salesforce may be among the first SaaS companies to push for improved MFA security, but certainly it won’t be the last.
Shivesh Rai 0 Reputation points

2026-02-25T07:12:08.4433333+00:00

@Herron, Scott So does it mean that now we need to create a custom claim "amr" and set its value to "multipleauthn" ?
Sorry if that sounds silly, but right now I am very desperate for a solution that works.

Also, do we need to make any change at Salesforce's end to accomodate this "amr" claim? We have simply setup a SSO configuration, and there is no Login Flow implemented to behave in a specific way in response to a SAML authentication.

Has anyone been able to implement this properly? If yes, please share the detailed steps on how to configure this on the Entra IDs end, as well Salesforce's end.

Answer 1

I was able to get Entra ID to return a usable MFA indicator without any special configuration in Entra, using a hint from this Microsoft doc (not obvious from the main SAML protocol docs):

https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-expected-inbound-assertions#using-saml-20-federated-idp

Key takeaway: if you need Entra to return http://schemas.microsoft.com/claims/multipleauthn as the AuthnContextClassRef, you must request it via RequestedAuthnContext, and it must be the first item in the list.

In my testing, if a custom/unknown AuthnContextClassRef appears before multipleauthn, Entra rejects the AuthnRequest immediately (instead of evaluating subsequent entries). So ordering matters.

Example AuthnRequest excerpt (works)

<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
  https://mydomain.com/myid
</saml:Issuer>

<samlp:NameIDPolicy AllowCreate="1" />

<samlp:RequestedAuthnContext Comparison="exact">
  <!-- MUST BE FIRST -->
  <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    http://schemas.microsoft.com/claims/multipleauthn
  </saml:AuthnContextClassRef>

  <!-- Additional values (including custom ones) can follow -->
  <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    urn:pingidentity:pingone:authn:web_login_otp
  </saml:AuthnContextClassRef>
  <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    urn:pingidentity:pingone:authn:web_login_fido
  </saml:AuthnContextClassRef>
  <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    urn:pingidentity:pingone:authn:web_login_email
  </saml:AuthnContextClassRef>

  <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI
  </saml:AuthnContextClassRef>

  <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    https://refeds.org/profile/mfa
  </saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>

What Entra returns (important bits)

With the request above, Entra returned:

AuthnStatement/AuthnContextClassRef = http://schemas.microsoft.com/claims/multipleauthn

and also included the authnmethodsreferences attribute showing the methods used, e.g.:

<Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences">
  <AttributeValue>
    http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password
  </AttributeValue>
  <AttributeValue>
    http://schemas.microsoft.com/claims/multipleauthn
  </AttributeValue>
</Attribute>

<AuthnStatement ...>
  <AuthnContext>
    <AuthnContextClassRef>
      http://schemas.microsoft.com/claims/multipleauthn
    </AuthnContextClassRef>
  </AuthnContext>
</AuthnStatement>

Example Shibboleth SP Apache config

AuthType shibboleth
ShibRequestSetting requireSession On
ShibRequestSetting redirectToSSL 443
ShibRequestSetting REMOTE_ADDR X-Forwarded-For
ShibRequestSetting forceAuthn On
ShibUseEnvironment On

<RequireAll>
  ShibRequestSetting authnContextClassRef "\
    http://schemas.microsoft.com/claims/multipleauthn \
    urn:pingidentity:pingone:authn:web_login_otp \
    urn:pingidentity:pingone:authn:web_login_fido \
    urn:pingidentity:pingone:authn:web_login_email \
    urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI \
    https://refeds.org/profile/mfa"

  ShibRequestSetting authnContextComparison exact
  Require shib-session

  # Explicitly deny "unspecified"
  <RequireNone>
    Require authnContextClassRef urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
  </RequireNone>

  # Allow any of the above
  <RequireAny>
    Require authnContextClassRef "http://schemas.microsoft.com/claims/multipleauthn"
    Require authnContextClassRef "urn:pingidentity:pingone:authn:web_login_otp"
    Require authnContextClassRef "urn:pingidentity:pingone:authn:web_login_fido"
    Require authnContextClassRef "urn:pingidentity:pingone:authn:web_login_email"
    Require authnContextClassRef "urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI"
    Require authnContextClassRef "https://refeds.org/profile/mfa"
  </RequireAny>
</RequireAll>

Bottom line: If your SP/app needs Entra to emit a strong auth signal, requesting http://schemas.microsoft.com/claims/multipleauthn (and putting it first) can cause Entra to return it directly in AuthnContextClassRef, plus the authnmethodsreferences attribute values. This worked for me with Shibboleth SP without making any changes in Entra itself.

Answer 2

Rahul Shah 5

We are running into issues with SAML SSO integration with Salesforce. We have the amr attribute claim added as shown in the image below. Additionally, we have Conditional Access Policy setup to enforce MFA when users SSO to Salesforce. But, even with all this configurations, users are enforced to setup Salesforce MFA. Is there anything we are missing? As per Salesforce support, they are only receiving password in SAML response. What additional configuration is needed so users do not have to setup Salesforce MFA and they receive both password and/or MFA? Please advise.

0 comments

Answer 3

To specify an AuthnContextClassRef in a SAML response when using Microsoft Entra, you need to ensure that your SAML requests include the appropriate AuthnContext settings. Here are some steps and configurations you can consider:

Include AuthnContext Class References: When you configure your SAML authorization request, you can include the AuthnContext element with specific class references that reflect the authentication methods you want to support. For example, you can specify MFA or Smartcard authentication methods in the request. Example:
```
   <samlp:AuthnRequest AssertionConsumerServiceURL="https://..."
                       IncludeAuthnContextClassReferences="urn:oasis:names:tc:SAML:2.0:ac:classes:Password,urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
       ...
   </samlp:AuthnRequest>
```
Force Authentication: If necessary, you can force a fresh authentication by including the ForceAuthN="true" attribute in your SAML request. This ensures that the user is re-authenticated and that the correct AuthnContext is used in the response. Example:
```
   <samlp:AuthnRequest AssertionConsumerServiceURL="https://..."
                       ForceAuthN="true">
       ...
   </samlp:AuthnRequest>
```
Check Application Configuration: Ensure that the applications you are integrating with (like Salesforce) are configured to accept the specific AuthnContextClassRef values you are sending. This might involve adjusting settings in those applications to recognize the authentication methods being used.
Review Conditional Access Policies: Make sure that your conditional access policies in Microsoft Entra are set up correctly to enforce the desired authentication methods and that they align with the expectations of the applications accessing them.
Testing and Validation: After making these changes, test the SAML response to ensure that the AuthnContextClassRef reflects the authentication method used. You may need to work with your identity provider to verify that the correct values are being sent in the SAML assertions.

If Microsoft Entra does not automatically recognize or report the authentication methods correctly, you may need to consult the documentation or support for further assistance on how to configure these settings effectively.

References: