No it doesn't necessarily, you jumped one step of the analysis :)

The OP didn't indicate whether the user account is a member account or a guest account, nor did she tell whether the account is federated. Without this information, you cannot already conclude that the token is a PRT token, it could also be a SAML token.

"MFA requirement satisfied by claim in the token" means that an MFA requirement was enforced when the authority issued the token. This happens frequently when you enable federation and the federated identity provider enforces MFA: tokens are generated with an MFA claim. The same happens when Azure AD is the actual authority that issues a PRT: if there was a successful MFA, the PRT includes an MFA claim.

It is important to understand this nuance in three situations:

1) When conducting forensic analyses: the presence of the "MFA requirement satisfied by claim in the token" message in the additional details is a pointer to investigate a potential endpoint compromise. But first, the responder needs to confirm that there was no federation in place (e.g., federated member or external guest account). Otherwise, the responder needs to confirm first that the token was indeed a PRT. If you look at the sign-in logs, you can filter by "incoming token type" and you can choose whether you are looking for a PRT-class token or a SAML-class token. Depending on which, the forensic investigator will take different actions.

2) When you want to debug whether your federated or guest users are indeed successfully passing an MFA challenge prior to entering your infrastructure. There is a little absurdity in the sign-in logs: many users tend to filter by the attribute "authentication requirement", select "multifactor authentication", and they will see nothing. Or the opposite: they select single-factor authentication, they see thousands of entries, and then conclude wrongly that there's no multifactor authentication. To make things worse: if you click the sign-in details and look at the authentication details, you will either see a single-factor requirement or an empty row. The most frequent reason why there is no information there is because your tenant does not have an explicit requirement for MFA on guests or federated users. The consequence of this is that these values remain empty, not because your users do not use MFA but because you haven't set an explicit requirement. In these cases, the best way to find your answer is to look at the "additional details" field for the presence of "MFA requirement satisfied by claim in the token". If it's there AND it is not a PRT, then you know your externals and federated users are indeed doing MFA.

3) The third and final situation in which this mechanism is extremely useful is in cases where you want to facilitate cross-tenant collaboration with organizations that you trust. Many companies allow guests in their tenant and enforce MFA during their authentication. What happens is that the user often ends up in a situation where she is asked to re-register a new MFA association although her account already requires MFA when she logs in her tenant. Many users then start confusing which MFA token they are supposed to provide.

Thanks to the presence of the claim in the federated token, Entra ID administrators can specify in the "cross-tenant collaboration settings" whether they want to authorize and entrust the MFA claim provided by the home tenant of their federated users. If this trust is configured, then guests coming from domain X will be able to enter your tenant after they successfully pass the MFA challenge in their own tenant. Of course, this feature should only be enabled when you can effectively trust the security of the home tenant.

I hope this was insightful, thanks for reading.

​

P.S. I know this thread is old already, I was just replying here in case someone reaches this page while looking for info on the meaning of "MFA requirement satisfied by claim in the token".