The MFA Coverage Audit: Finding the Doors Without Locks
"MFA is enabled" is not a posture statement. Coverage is. A working checklist for finding every door that can still authenticate without it — legacy protocols, service accounts, and the recovery paths that quietly undo everything.
"We have MFA" is the single most misleading sentence in an identity review. It is almost always true and almost never sufficient, because MFA is not a property of an organization — it is a property of each individual door that can authenticate, and organizations have far more doors than anyone has counted. Snowflake wasn't breached because MFA didn't exist; it was breached because MFA was available and a few hundred accounts could still log in with just a password. The gap between "enabled somewhere" and "required on every authenticating surface" is the entire subject of this checklist.
The posture question is not do you have MFA. It's what fraction of the ways into this tenant actually require a phishing-resistant factor, and do you even have the inventory to answer that. Coverage is a number. Presence is a feeling. Below is how to turn the feeling into the number.
Why coverage, not presence
A coverage audit is just an inventory of authentication surfaces, each marked covered or not. The work is not technical — it's that the inventory is scattered across systems nobody thinks of as "login." The web SSO portal is the door everyone secures. The doors people forget are the ones attackers actually use: a legacy mail protocol, a service account, a help-desk reset. You are looking for the surfaces that can mint a session without passing through the front door you hardened.
Run the audit per tenant, write down the answer, and report the percentage alongside your findings. A blank box below is not a finding to fix later — it is an open door right now.
The audit
Human interactive logins
- Primary SSO / IdP web login requires MFA for all users, not most
- Admin and privileged consoles require a phishing-resistant factor (WebAuthn / hardware key), not just any second factor
- Cloud provider root / break-glass accounts are enrolled and the factors are stored where you can actually find them
- Contractors, interns, and temporary staff are inside the same policy, not a looser exception group
- No "MFA-exempt" trusted-network or trusted-IP bypass that a VPN or office presence silently satisfies
Legacy and non-interactive protocols — the usual blind spot
- Legacy mail auth (IMAP, POP3, SMTP AUTH) is disabled, not just "discouraged" — these don't speak MFA and never will
- Basic auth / legacy auth is blocked at the IdP, not left on for "that one old client"
- RDP, VPN, and RADIUS front-ends sit behind MFA — these are the warehouse-PC and remote-access surfaces that web-first tooling forgets
- LDAP / directory binds used by on-prem apps can't be used to sidestep the federated login path
- No app or integration is configured to use a username/password where a federated, MFA-bearing flow exists
Service and non-human accounts
- Every service account that can do an interactive-equivalent login is inventoried and owned by a named person
- API keys and long-lived tokens that substitute for a password are catalogued with an issue date and an expiry
- OAuth client credentials and connected-app grants are treated as authenticating surfaces, because they are
- No shared/team account quietly exempt from MFA because "a person can't carry the token"
Fallback and recovery — where coverage silently leaks
- SMS and voice OTP are removed as factors where anything stronger is enrolled — a fallback to SMS is a fallback to phishable
- Backup codes are accounted for and can't be socially engineered out of a user
- Help-desk MFA reset has its own harder procedure for privileged accounts — the MGM and M&S door is the reset path, not the login
- Self-service recovery flows can't re-enroll a weak factor that bypasses the strong one
- Outsourced service-desk staff operate under the same recovery friction as internal staff, with the same logging
Federation edges
- Inbound federation / guest access from partner tenants inherits or exceeds your factor requirements
- SAML/OIDC trust relationships can't be used to assert an identity that skipped MFA upstream
Turning the boxes into a posture number
Count the surfaces. Count the covered ones. Report covered ÷ total per tenant, and report it next to your findings, never instead of them — because a tenant with zero open findings and 60% coverage isn't clean, it's unmeasured. The blank boxes are your real backlog, ranked by exposure: a privileged console without phishing-resistant MFA outranks a forgotten IMAP endpoint on a dormant tenant, which outranks a cosmetic gap. That ranking is the deliverable. "We have MFA" can't be ranked, prioritized, or trended — which is exactly why it isn't posture.
The uncomfortable part of every coverage audit is that the number is always lower than the org expected, because the doors they forgot are, by definition, the ones they weren't counting. That's not a failure of the audit. That's the audit working.
At Aurelion, turning "we have MFA" into an honest per-tenant coverage number — across legacy protocols, service accounts, and recovery paths — is squarely the kind of last-mile work we build for. If you're running this audit by hand across a fleet of clients, I'd like to compare notes.