Identity · Phishing-resistant MFA
Most MFA is still phishable.
IronSights rolls out passkeys and FIDO2 security keys across Microsoft Entra ID and Google Workspace, then enforces them properly. Registration first, enforcement second, nobody locked out.
If a code can be typed into a fake page, it can be forwarded to the real one within seconds. SMS and authenticator apps both fail that test, and so do push approvals. Domain-bound credentials are the answer, and they cost less to deploy than most people expect.
Our methodology
Registration first. Enforcement second.
These projects fail in a predictable way. Enforcement is switched on before people have registered, the support queue fills up by mid-morning, and the change gets rolled back and never revisited.
We measure registration coverage from your own sign-in data before enforcing anything, and break-glass accounts are excluded and tested first.
Assess
Audit which authentication methods are actually in use across your tenant, and where SMS or app codes are still accepted as a fallback on privileged accounts.
Design
Map staff into cohorts. for most people. FIDO2 security keys for administrators and break-glass accounts, plus anyone the app-based route cannot reach.
Register
Run a pilot group, then open registration to everyone with a deadline and real support. Coverage is measured from sign-in data, not assumed.
Enforce
Require a method through . Scope it narrowly, then widen it. Weaker methods are removed only once coverage is genuine.
What's included
The work is the policy, not the hardware.
Buying keys satisfies nothing on its own. What closes the gap is the enforcement policy, the coverage behind it, and the evidence that both are real.
Authentication method audit
Which methods your tenant accepts today, and where a weaker fallback quietly undermines the stronger requirement sitting next to it.
Cohort design
Who gets a , who needs a hardware key, and who is currently unreachable by either. The last group is the one that stalls rollouts.
Hardware key sizing
How many keys, and which models for whom. Two per person in scope, then dedicated break-glass pairs and a spare pool held by IT.
Authentication strength policy
configured to require a method for the accounts in scope, rather than accepting any MFA and calling it done.
Legacy method removal
SMS and voice codes retired in the right order, then app codes. Left enabled, they are the fallback an attacker uses instead of the control you deployed.
Privileged account hardening
Global Admin and privileged roles moved to hardware-backed credentials, with device and location conditions applied on top.
Break-glass accounts
Emergency access accounts created, excluded from the policies that could lock them out, with keys stored securely and access tested.
Joiner and leaver process
Registration built into onboarding and revocation into offboarding, so coverage does not decay three months after the project ends.
What actually qualifies
The test is domain binding. A credential that will only sign for the site it was created for cannot be handed to an attacker by a user who has been fooled.
- FIDO2 security keys
- Passkeys, synced or device-bound
- Passkeys held in Microsoft Authenticator
- Certificate-based and smart card logon
- Windows Hello for Business
What does not
Anything a person can read off one screen and type into another. If the user can be persuaded to enter it somewhere, so can the attacker relaying it.
- SMS codes, also exposed to SIM swapping
- Authenticator app codes
- Push approvals with approve and deny
- Number matching push, better but still relayable
- Email codes and voice call verification
Enforcement in Microsoft Entra ID
enforces this through authentication strengths, which require a method without dictating which one. Different cohorts can carry different credentials under a single policy.
That flexibility is what keeps the cost sensible, and the scoping is where the risk sits. A policy applied too broadly, or without break-glass exclusions in place, locks administrators out of the tenant.
- Authentication strengths per cohort
- Privileged roles on hardware-backed credentials
- Break-glass accounts excluded and tested
- Registration coverage measured, not assumed
What you gain
The password is stolen, and it does not matter.
Four outcomes from every engagement, measured against your own sign-in data rather than asserted at handover.
Credential phishing stops working
A credential is bound to the real domain and will not sign for an impostor. A convincing fake login page collects nothing it can use.
Proxy attacks defeated
Attacker-in-the-middle kits relay codes and session tokens in real time, which defeats app codes and push approvals. Domain-bound credentials do not respond to them at all.
Fewer prompts, not more
A or a key touch replaces typing a six-digit code. Staff usually find the stronger method faster than the one it replaced.
Evidence you can hand over
Coverage figures documented alongside the policy configuration and its exclusions, which is what an assessment or a question actually asks for.
Common questions
Phishing-resistant MFA questions answered.
Not sure whether the MFA you already have would survive a convincing fake login page? Contact us and we will tell you where you actually stand.
Talk to a specialist →What does phishing-resistant MFA actually mean?
A method is when an attacker cannot use it even if the user falls for the fake page. The property that achieves this is domain binding: the credential is tied to the legitimate domain and will not produce a signature for any other one. The user cannot be tricked into overriding that, which is what separates it from methods that merely feel strong.
Is Microsoft Authenticator phishing-resistant?
It depends which method you have deployed. A in Microsoft Authenticator is . Push approvals and the six-digit codes from the same app are not. A great many organisations believe they have the first and have actually rolled out the second.
What about number matching?
Number matching is not , because an attacker-in-the-middle proxy can relay the displayed number as easily as the user can read it. It does genuinely reduce fatigue attacks and it is worth enabling, so treat it as a useful improvement to a phishable method rather than a replacement for a domain-bound one.
Do we have to buy hardware keys for everyone?
Almost never. Most organisations cover general staff with , which cost nothing, and buy FIDO2 security keys for privileged accounts, break-glass accounts and the staff that passkeys cannot reach. That last group is usually people without a work phone, shared workstations, and roles where phones are impractical. The key count is normally a fraction of headcount.
Will this lock people out?
Not if it is sequenced properly. Registration comes first with a deadline and support, enforcement is scoped narrowly and widened in phases, and break-glass accounts are excluded and tested before anything is enforced. The lockouts happen when enforcement is switched on before registration coverage is real, which is the most common way these projects fail.
Does this satisfy the Essential Eight?
The addresses the strength of the authentication method, not only whether MFA exists, and the maturity levels distinguish between weaker and stronger methods. Moving to methods is the substance of that requirement, though the evidence and coverage matter as much as the technology. We confirm where you actually sit as part of an Essential Eight assessment.
Does this work with Google Workspace as well as Microsoft?
Yes. The credentials are the same standard either way. What differs is the enforcement mechanism, which is in and organisational unit policy in Google Workspace, and the sequencing that keeps you from locking yourself out of your own domain.
Is this included in Fortify managed security?
Yes. Authentication method policy design and ongoing review is part of a Fortify engagement. We also run it as a standalone project for organisations that manage their own environment day to day.
Already rolled out MFA?
Find out whether it would survive an attack.
Most environments accept a weaker fallback alongside the strong method, which means an attacker simply uses the fallback. We find those gaps and close them in an order that does not lock anyone out.