By Luffy Bao, CTO at Ankayma · 9 August 2026 · ← All writing
Last week I was hand-testing our own step-up flow — the extra confirmation we ask for before a sensitive action. I had Touch ID enrolled, which is the strongest thing we support on a laptop: a key that lives in the Secure Enclave and cannot be copied out. The prompt appeared. I cancelled it. The system offered my authenticator app. I cancelled that too. It then offered to email me a code. I pasted the code in, and the sensitive action went through.
Nothing had failed. Every component did exactly what it was written to do. And that is the uncomfortable part: the account with the strongest factor enrolled was still protected by the weakest one, because the weakest one was never switched off.
Why the assurance level didn't catch it. Authentication frameworks give you assurance levels, and the natural instinct is to enforce them: this action requires level two, so accept anything that reaches level two. We did exactly that. The problem is that a platform key in a Secure Enclave, a time-based code from an authenticator app, and a code emailed to you all carry the same level on paper. A check that reads "is this at least level two?" cannot tell them apart, because all three answer yes. The gate passed. The downgrade happened inside a single assurance level, where a threshold has nothing to grip.
This is worth sitting with if you build authentication. An assurance level is a floor, not an ordering. It tells you what is unacceptable. It does not tell you that of two acceptable options, one is phishable over a channel an attacker may already read, and the other requires physical possession of a device that will not export its key.
Email was never supposed to count in the first place. NIST is explicit: email shall not be used as an out-of-band authentication channel. Not "is weaker" — shall not. An inbox is a general-purpose account reachable from anywhere, frequently protected by a password, and often the same account used to reset everything else. Treating it as a second factor mostly proves the attacker still has the thing they took first.
And this has a name. A downgrade attack doesn't break your strong factor; it walks around it. The attacker never needs to defeat the Secure Enclave — they only need the weak path to still exist, and a reason for the user to take it. "Your fingerprint reader isn't working, use the emailed code" is not a sophisticated exploit. It's a support script. Earlier this year, researchers demonstrated a downgrade that bypasses FIDO authentication in Microsoft Entra ID by forcing a fallback to a weaker method. Big vendor, real implementation, same shape.
Where the fix actually lives. Our first instinct was to adjust the numbers — raise the level the action demands. That would have been the wrong repair: it would either break users who legitimately have only the weaker factor, or leave the same hole one tier up. The real fix sits at the moment the challenge is issued. Before sending an emailed code, ask what this account already has. If it has a platform key or an authenticator app enrolled, refuse to issue the email challenge at all for ordinary actions, and say so plainly. Then refuse it again on the verifying side, because an older client can still call that endpoint directly and the server is the only place that can't be bypassed. Finally, record the attempt: a request to step down to the weak factor on an account holding a strong one is exactly the signal CISA recommends alerting on, and it costs almost nothing to write down.
Don't skip the cost — this is a trade, not a free win.
Let me state my bias. We build access infrastructure, so I have an interest in you caring about this. Weigh that. The narrow claim doesn't depend on trusting me, though: if your system offers more than one way to satisfy the same requirement, users and attackers will both find the cheapest one — and the cheapest one is your actual security posture, whatever your documentation says about the strongest.
The question worth running forward. Take an account at your company with the best factor you support enrolled. Now assume the attacker already has the password and can read the inbox, which is what most credential dumps and mailbox compromises give them. Cancel your way down the prompts, the way an impatient user would. What is the last door still open, and who decided it should be? If nobody decided — if it is open because it was never turned off — then that door, not the one you shipped proudly, is the one holding your production access.
We found this by using our own product like a user, not by reading our own spec. Our written rule had been right for weeks; the code had never enforced it. If you're building step-up flows and want to compare notes on where you drew the line — especially if you think we drew ours in the wrong place — I'd like to hear it.
Sources: NIST SP 800-63B §5.1.3.1 (out-of-band authenticators; email shall not be used); OWASP ASVS discussion #1046 (email authenticators vs 800-63); CISA, Phishing-Resistant MFA guidance and FIDO success story (including alerting when a passkey holder authenticates with a weaker method); BleepingComputer (2026), downgrade attack bypassing FIDO authentication in Microsoft Entra ID.
Luffy Bao is CTO at Ankayma, building zero-trust mesh infrastructure for regulated organizations in Southeast Asia and the Gulf. Questions or counterarguments? hello@ankayma.com