Phishing-Resistant MFA: A Practical Rollout for UK Businesses

Phishing resistant mfa uses cryptographic authentication bound to the legitimate website or application. A fake login page cannot capture an authentication secret and replay it against the real service.

That definition excludes several methods routinely marketed as strong MFA. SMS, one-time codes, push approval and number matching can reduce risk, but they do not remove the phishing route.

What phishing resistant mfa is — and what it is not

Passkeys and FIDO2 security keys use WebAuthn to verify the website or application requesting authentication. The authenticator will only respond to the correct relying party, so an attacker-controlled domain cannot use the resulting cryptographic proof.

Practical phishing-resistant MFA examples include:

• Platform passkeys protected by a device PIN or biometric
• FIDO2/WebAuthn hardware security keys
• Windows Hello for Business
• Certificate-based authentication, when the certificates, devices and trust chain are managed correctly

A passkey can satisfy multiple factors. The registered device provides possession, whilst its local PIN or biometric supplies user verification. Passwordless authentication is not necessarily single-factor authentication.

The distinction matters because conventional MFA still produces information or actions that an attacker can relay:

Origin binding is the decisive property. Extra prompts do not create it.

Stop treating successful phishing as an employee mistake

A login flow that allows a user to hand reusable credentials to the wrong website is designed to permit phishing failure. Training may reduce how often that happens, but it leaves the system dependent on every person correctly inspecting every login page, redirect and approval request.

Adversary-in-the-middle phishing kits proxy the genuine service in real time. The victim enters a password and one-time code into the attacker’s page; the kit relays both to the real service and captures the resulting session.

Number matching makes blind push approval harder, which is useful. It does not stop a fake site from displaying the same number shown by the genuine authentication session and instructing the victim to approve it.

Awareness training still has value. Staff should know how to report suspicious messages, protect recovery channels and recognise unexpected authentication prompts. But training is a supporting control, not a replacement for an authentication protocol that rejects the wrong origin automatically.

Phishing resistance is an engineering decision. The system, rather than the employee, should enforce where credentials can be used.

The options we would deploy for a UK business

For most employees, we would make device-bound or managed platform passkeys the everyday default. They combine origin-bound authentication with an interaction users already understand: unlock the device with a fingerprint, face check or local PIN.

We would issue at least two hardware security keys to administrators, finance staff, developers with production access and other high-impact users. The spare should be registered in advance and stored separately, not left in the same laptop bag.

Hardware keys for every employee are not automatically the best policy. A managed platform passkey can provide the same essential origin-bound protection with less equipment to distribute, replace and support. Hardware keys earn their overhead where account compromise would have an unusually large impact or users work across shared and unmanaged devices.

Synced passkeys can improve usability across several devices. Before allowing them, we would assess:

• Who owns and controls the devices
• Which passkey providers are permitted
• Whether business credentials can sync to personal accounts
• How access is removed when somebody leaves
• What happens when a provider account is recovered or compromised

Certificate-based authentication belongs in organisations that already operate sound public key infrastructure, device management and certificate lifecycle processes. Introducing PKI solely to avoid deploying passkeys usually creates more operational risk than it removes.

Authentication changes often touch SSO, account recovery, device enrolment and application integrations. They should be treated as a software and systems project, much like the integration work in our custom web application development, rather than as a switch somebody enables on Friday afternoon.

Microsoft Authenticator, Entra and Conditional Access

Normal Microsoft Authenticator push notifications are not phishing-resistant. Number matching improves push security but remains relayable. Passkeys stored and used through Microsoft Authenticator are a different authentication method and can provide phishing resistance because they use origin-bound cryptography.

Microsoft Entra ID is the current name for Azure Active Directory. Teams still searching for “phishing resistant mfa Azure” are generally looking for Entra authentication strengths and Conditional Access.

We would create a phishing-resistant authentication strength and apply it first to:

• Privileged administrator roles
• Production and security tooling
• Finance and payment systems
• Sensitive applications
• Access judged risky under the organisation’s identity policy

A controlled deployment needs registration campaigns, managed-device rules, representative test groups and sign-in-log monitoring. Emergency access accounts require explicit exclusions, strict restrictions and alerts; they should not be accidentally caught by a policy they exist to recover.

The common mistake is enabling a strong method but retaining password-plus-code fallback on the same account. An attacker will use the weakest accepted path. The effective protection is therefore defined by every permitted login and recovery route, not the strongest method listed on an enrolment screen.

Microsoft changes administration screens and capabilities over time. Implementers should work from the current Microsoft documentation for authentication strengths, passkeys in Microsoft Entra ID, Conditional Access and emergency access accounts, then verify behaviour in a test tenant before enforcement.

Apply the same policy to Salesforce and Duo

For Salesforce, first establish where authentication is controlled. If Salesforce is already federated through Entra or another established identity provider, central enforcement usually produces a clearer policy and better audit trail than maintaining separate MFA rules in both systems.

Direct Salesforce logins still need attention. Federation does not protect an unmanaged direct-login route, an emergency administrator account or an overlooked community and mobile login flow. Those paths must be restricted or protected independently.

For Duo, ordinary Duo Push and Verified Push are not equivalent to FIDO2/WebAuthn. Additional checks can reduce accidental approvals and push fatigue, but they do not provide the same cryptographic binding to the genuine application. Duo-supported security keys and passkeys can.

Vendor labels are less useful than the protocol underneath them. “Advanced MFA” may mean a better push prompt, a passkey or a certificate, and those methods have materially different resistance to relay attacks.

Because product tiers, policy names and administration screens change, deployment teams should use the vendors’ current configuration documentation. For Salesforce, check its current MFA and WebAuthn guidance; for Microsoft, use the Entra authentication-strength and passkey documentation; for Duo, use its current passkey, passwordless and FIDO2 security-key documentation. The policy design should survive a renamed menu.

A rollout that does not lock out the business

Start with an inventory of users, devices, applications, service accounts, legacy authentication protocols and recovery paths. Include remote workers, contractors, shared workstations, mobile applications and systems that bypass the primary identity provider.

Pilot with the technical team, followed by administrators and high-risk departments. Record enrolment failures, unsupported devices, broken application journeys and support requests. A pilot is meant to expose assumptions, not prove that the policy screen accepts a configuration.

Each high-impact user should have more than one registered phishing-resistant authenticator. Test lost keys, replacement phones, rebuilt laptops, leavers and staff working remotely without access to an office.

Create monitored break-glass accounts with long random credentials, restricted permissions where possible and credentials held securely offline. Their use should generate an immediate alert. Do not weaken the everyday policy for the whole organisation just to make emergencies easier.

Only remove legacy authentication and weaker fallback methods after sign-in telemetry shows that users and applications have migrated. This sequencing avoids lockouts without leaving old routes available indefinitely.

Where several applications and identity systems must exchange enrolment or access data, targeted business automation and integration work can remove brittle manual steps. It should not automate approvals that require security judgement.

The implementation checks most MFA guides omit

Test the complete login journey, not only the identity provider’s demonstration page. That means SSO redirects, custom domains, mobile applications, embedded browsers, delegated administration and every recovery route.

Recovery must not be weaker than primary authentication. If somebody can bypass a security key through a support call or emailed reset link, the account is only as phishing-resistant as that recovery process. Help-desk staff need a defined verification procedure and limited authority.

Keep human authentication separate from workload authentication. Service accounts and integrations should use managed identities, workload identity federation or narrowly scoped credentials. Shared accounts with improvised MFA exceptions are difficult to attribute, rotate and remove.

Log and alert on:

• Registration of new authentication methods
• Removal or replacement of authenticators
• Conditional Access and identity-policy changes
• Failed and successful recovery attempts
• Direct logins that bypass expected federation
• Any use of emergency access accounts

The success measure is not the percentage of users marked as having MFA. It is whether phishable routes to sensitive systems have actually been removed.

If you want us to review the authentication flows in a web application or plan a safer rollout, start a technical conversation with us.