Why "MFA is already on" is not enough
Consider a hypothetical enterprise that enabled multi-factor authentication for all staff two years ago, mainly through SMS codes and push approvals on mobile phones. One day a finance employee typed a password and a code into a fake sign-in page, and the attacker immediately used them to sign in to the mailbox and create a forwarding rule. On another occasion an operations administrator received dozens of push requests late at night and, half awake, tapped approve. The review afterwards found that the problem was not the absence of MFA. It was that all these methods rely on the user judging whether the page or request in front of them is genuine. Once the user is deceived, the second factor is handed over too.
In the fourth revision of its digital identity guidelines, finalized in July 2025, NIST updated the authentication assurance levels. At the second level, verifiers shall offer at least one phishing-resistant option and should encourage its use where practical. The third level requires a cryptographic authenticator with a non-exportable private key that provides phishing resistance. The guidelines also classify SMS and telephone channels as restricted authenticators that require a risk assessment and an alternative. These requirements are aimed directly at federal systems, and enterprises can use them as a direction: the key to phishing resistance is that the authenticator checks which site or service is actually being accessed, so when a user is lured to a fake page, the credential does not work there.
Rank accounts by risk
Switching everyone at once tends to cause a flood of help requests and resistance, so JOTOglobal suggests that the identity administrator and the security lead first set an order by risk. The first batch is accounts that can change other people's permissions or reach large amounts of data: domain administrators, administrators of cloud and identity platforms, management accounts for network and security devices, and mail administrators. The second batch is roles that are often impersonated or can initiate payments directly, such as finance approvers, procurement, executive assistants and customer service leads. The third batch is general staff and contractors. For each batch, record the systems involved, the departmental contact driving the work and the planned completion date, and note which older systems do not yet support the new methods and need separate interim measures.
When choosing authenticators, first confirm which phishing-resistant methods the identity platform and key applications actually support, such as device-bound passkeys, hardware security keys or authenticators built into the platform, and then decide how to issue them by role. Administrators and high-risk roles should get device-bound authenticators with non-exportable private keys first, and each person should have a backup authenticator stored separately. If the organization allows syncable passkeys, it should assess how well the syncing account itself is protected. The procurement and asset teams record each issue, including the authenticator number, recipient, issue time and the person who registered it, so that a lost device or a departure can be traced and revoked quickly. Recovering authenticators should also be part of the offboarding checklist, with the direct manager confirming that the device has been returned or revoked in the identity platform.
Design recovery and exceptions at the same time
After phishing-resistant authentication is rolled out, the weakest point often moves to account recovery. If an attacker calls the service desk claiming a lost phone and the desk resets authentication on the spot, the earlier investment is bypassed. The service desk recovery process should therefore require verified identity confirmation, such as a video check combined with confirmation from the direct manager, or an in-person check of identification, and should notify both the user and the manager after a reset. Recovery for administrator accounts should be performed by two people together, with a ticket kept. For people or systems that cannot yet use the new methods, record the reason for the exception, the approver, the compensating controls and an expiry date, and reassess on expiry rather than keeping SMS as a long-term back door.
During the rollout, the identity administrator should narrow the use of older methods in parallel. Users who have registered should no longer be able to fall back to SMS or push approval in key applications. Groups that still use push should at least have number matching or sign-in location displayed as extra cues, with alerts for unusual requests. The service desk needs an operating guide and FAQ in advance, and training should focus on recognizing impersonated help requests and how to report them, not just on demonstrating device registration. If a business system can only use the old methods, list it as a separate risk item and have the system owner propose a plan to upgrade or replace it.
Acceptance evidence, common mistakes and limits
Acceptance is led by the security team. Evidence includes statistics exported from the identity platform on authentication methods by batch, showing that all administrators and high-risk roles have registered phishing-resistant authenticators; policy screenshots or exports proving that key applications no longer allow fallback to older methods; a record of a fake-page test in an authorized test environment showing that the new authenticator cannot complete sign-in on the imitation site; and spot-check records of the service desk recovery process. One common mistake is to count only the share of accounts with MFA enabled without distinguishing the method. Another is to leave exceptions open without review, so that the most sensitive accounts end up still using methods that can be phished.
The batch order, recovery process and acceptance items in this article are organizational guidance from JOTOglobal. The mandatory provisions in the NIST guidelines apply to U.S. federal agencies, and enterprises should judge applicability against regional regulations, industry requirements and their own system capabilities. Phishing-resistant authentication mainly reduces the risk of credentials being tricked out of users or relayed through an intermediary proxy. It does not prevent a signed-in device from being controlled by malware, session tokens from being stolen or insiders from abusing permissions, which still require endpoint protection, session management and permission audits. Completion dates for each batch and exception periods should be set by each enterprise according to its headcount and the effort of upgrading its systems.