· Yair Knijn
The MFA everyone assumed was on everywhere, except the three apps with local logins
The CISO pulls the number from the identity provider: MFA satisfied on 100% of sign-ins, conditional access enforced, no exceptions. That slide goes to the board and the cyber insurer. It is true, and it is also the wrong number, because the IdP only reports on the logins it actually sees.
Three apps in the estate never federated. A scheduling tool from an acquisition, a finance reporting portal nobody wanted to re-procure, and a vendor extranet that "supports SSO on the Enterprise tier" the company never bought. Each keeps its own password table. None route through conditional access, so none appear in the coverage number at all. The dashboard isn't lying; it's measuring the wrong perimeter.
Why IdP-reported MFA coverage is not estate coverage
Conditional access evaluates a sign-in only when it reaches the identity provider. An app that authenticates against its own local store completes the whole flow before the IdP is ever consulted, so there is no event to evaluate and nothing to count as uncovered. Your 100% is a percentage of federated logins, not of the estate, and the denominator quietly excludes exactly the apps you are worried about.
This is the same blind spot that lets legacy authentication clients slip past policy. Microsoft's own guidance is blunt that sign-ins from legacy auth don't support MFA and don't carry device state, so the recommended posture is to block them outright. The local-login app is that problem with a friendlier face: not protocol abuse, just a product that never asked your IdP for permission.
The local-login bypass: legacy apps that never see conditional access
Attackers reach these apps the way everyone does, by typing a URL and a password. Credential-stuffing operators replay breach-corpus passwords against any login form they find, and a finance portal with a local password table and no MFA is a clean target. The federated front door has a guard checking ID. The side door from the 2019 acquisition has a sticky note with the combination.
What makes it dangerous is that the side door is often the same person's password. A reused credential that would be stopped cold at the IdP sails through the local form, and now an attacker has a session inside a system that holds real data and often links back out to the apps that are protected.
Finding every authentication path in the estate, not just the federated ones
You cannot find these from the IdP, because its entire job is to not see them. The inventory comes from the other direction. Practical sources that surface a local-login path:
- The SaaS spend list from finance, reconciled against the IdP's enterprise-app catalog. Anything billed but not federated is a candidate.
- IdP logs showing zero or near-zero sign-ins for an app in active use, which usually means the real logins happen where the IdP can't see them.
- Password-manager and browser-saved-credential telemetry, which reveals where staff actually keep local passwords.
- Egress and DNS logs for SaaS domains with no federation entry.
The deliverable is not a coverage percentage. It is a list of every app and the authentication path it accepts, with local-login apps named individually so each becomes a decision, not an oversight.
Forcing all products through one identity with no local-login escape hatch
The fix is architectural, not a policy tweak. Every product authenticates through one identity, and the local login form is disabled, not merely discouraged. If a tool only offers local accounts on the tier you bought, that is a procurement decision with a security price tag. An app you cannot put behind your IdP cannot honestly be in your MFA number.
This is why Spot Suite gives every product one identity per Customer Environment and no local-login escape hatch: when the MFA question gets asked, the answer covers the whole estate, because there was never a second door to forget about. Our security page covers the model.