IdP enforcement gaps leave MFA everywhere only partly true

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Way Security's blog post: Identity provider coverage gaps leave MFA, conditional access and provisioning unenforced on unfederated applications.

Why it matters: This matters because IAM teams cannot claim enterprise-wide authentication control unless the identity provider actually governs every application in scope, including legacy and self-hosted systems.

Context

Enterprises often assume that an identity provider automatically extends policy across the whole application estate, but that assumption breaks when older systems, homegrown tools or vendor apps never federate in the first place. In those cases, the control plane exists on paper while the real access path sits outside it.

The practical IAM problem is not whether MFA, conditional access or session controls are effective in federated apps. It is whether the programme has a complete application inventory and a way to bring unfederated systems under the same governance model. Identity provider coverage is only real when the policy reaches the login boundary.

When identity policy stops at the app boundary, the organisation is left with a split estate: governed applications and exceptions that quietly become permanent. That is typical in complex enterprises, not an edge case.

Key questions

Q: How should teams close identity provider enforcement gaps across applications?

A: Close the gaps by moving authentication and policy enforcement into a central identity plane, then retiring app-local credentials where possible. Use SSO, federation, conditional access, MFA, SCIM-driven provisioning, and periodic access reviews to bring each application under the same control point. Where an app cannot integrate, wrap it with compensating controls such as PAM, network restrictions, and tighter session monitoring.

Q: Why do some applications stay outside MFA and conditional access policies?

A: Some applications stay outside MFA and conditional access because they do not route sign-in through the identity provider, or they use local accounts, legacy protocols, or embedded authentication that bypasses the policy engine. In that case, the identity provider has no enforcement point, so teams must add federation, proxy controls, or app-specific access controls to close the gap.

Q: What should IAM teams do with local application logins?

A: IAM teams should replace local application logins with federated authentication wherever possible, then map users to centrally governed roles and groups. When local accounts must remain, they should be inventoried, owned, and reviewed, with strong password controls, MFA where supported, and deprovisioning tied to the joiner-mover-leaver process. The parallel trust model exists because the application trusts its own credentials separately from the enterprise identity provider.

Technical breakdown

Why unfederated apps sit outside IdP enforcement

An identity provider can only enforce controls on applications that trust it for authentication and authorisation. When an app uses a local login page, an older protocol, or a vendor-specific sign-in flow that bypasses federation, the IdP has no interception point. That means conditional access, MFA, session rules and provisioning logic never reach the app, even if they are mature elsewhere in the estate.

Practical implication: Treat federation coverage as the actual control boundary, not the presence of an IdP licence or policy definition.

How SAML and SCIM extend policy reach

SAML carries authentication into the federated app, while SCIM extends lifecycle and provisioning control into that same application plane. Together, they let the IdP become the authoritative gate for sign-in and account state. The important detail is that these protocols only help where the target app can support or be wrapped by them; otherwise the control remains partial. See the Identity Assertion JWT Authorization Grant Guide.

Practical implication: Map which apps can be brought under standard federation and which require compensating controls or replacement.

Why local logins become the residual risk

A local login creates a parallel authentication path that sits outside central policy, even if the broader workforce already uses SSO. That path often survives because it is convenient, technically necessary, or commercially baked into the application. Over time, these exceptions become standing risk because they are harder to monitor, harder to revoke consistently and harder to subject to the same assurance checks as federated access. See the Workforce Identity Security Guide.

Practical implication: Inventory every non-federated sign-in path and treat it as an exception until it is removed or governed.

NHI Mgmt Group analysis

Coverage, not policy intent, is the real identity control metric. A board slide that says MFA is enforced across the enterprise can be technically true and operationally misleading at the same time. If the policy only applies where the IdP has reach, the organisation has partial enforcement, not universal enforcement. Practitioners should measure control scope by application coverage, not by the existence of a policy statement.

Unfederated applications create an enforcement blind spot that governance teams routinely undercount. Legacy systems, homegrown tools and premium-gated vendor apps are not edge cases in large estates; they are where the residual risk accumulates. The governance error is assuming the identity programme can compensate for application non-participation after the fact. In practice, the exception becomes the control boundary.

Local authentication is a parallel trust model, not a temporary inconvenience. When a system keeps its own login, it keeps its own rules, recovery flow and session behaviour. That means the organisation is not just missing a control, it is running two identity models at once. The implication is that identity standardisation must be judged by the number of apps brought under one policy plane, not by how elegant that plane looks in the IdP console.

Identity provider buying decisions should be assessed on reach, not feature density. Procurement conversations often focus on policy depth, but the harder question is whether the platform can actually govern the applications that matter most. If the estate still contains significant unfederated surface area, then reach and integration strategy deserve as much scrutiny as MFA strength or conditional access granularity.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
• Read next: Identity Provider and SSO Security Guide

What this signals

Policy coverage has to become an inventory problem, not a slide-deck claim. Security leaders should expect more scrutiny of which applications are actually governed by the IdP versus merely assumed to be. The next maturity step is to link access policy reporting to application coverage, exception handling and ownership so the gap is visible in operational terms, not just in executive language.

The most common failure mode is not weak MFA design, but incomplete control reach. Once teams can see which apps still use local authentication or separate sign-in logic, they can decide whether federation, compensation or retirement is the right path for each one.

For practitioners

• Audit federated versus unfederated apps Build a current inventory of every application that sits outside IdP enforcement, including legacy, homegrown and vendor-restricted systems. Rank them by data sensitivity, user volume and business criticality so the highest-risk gaps are visible first.
• Classify every local login as an exception Treat any app that still authenticates users outside the central identity plane as a standing exception until it is federated, wrapped or retired. Track who owns the exception, what policy gaps it creates and when it will be reviewed.
• Prioritise federation for high-value apps Focus first on the applications that handle production data or privileged workflows and that still bypass conditional access, MFA or session controls. Standard federation should be the default remediation path where the application can support it.
• Remove premium-tier authentication blockers Review whether commercial packaging is forcing security into a higher license tier and leaving the most important apps outside policy. Where that is the case, document the residual risk and compare it with the cost of compensating controls.
• Replace app-specific access logic with central policy Where separate sign-in rules have been built for individual apps, move those decisions back into the identity provider so access, provisioning and session controls are applied consistently across the portfolio. See the Workforce Identity Security Guide.

Key takeaways

• An identity programme is only as complete as the applications the IdP can actually govern, and unfederated systems remain outside central enforcement.
• Legacy, homegrown and commercially restricted apps are where identity control gaps usually persist, not where policy is strongest.
• The practical fix is to measure coverage by real application reach, then federate, wrap or retire the exceptions that keep local authentication alive.

Related NHI Mgmt Group resources: Identity Provider and SSO Security Guide · Workforce Identity Security Guide · IAM and Identity Provider Buyer's Guide · MFA Guide

Key terms

• Identity Provider: An identity provider is the system that authenticates a user or workload and issues the trust signal used by downstream applications. In federated environments, it becomes a high-value control point because compromise, misconfiguration, or over-trust at this layer can affect many services at once.
• Federation: Federation is the arrangement that lets one organisation accept identity assertions from another trusted identity provider. It reduces separate credentials, but it also creates dependency on token validation, trust configuration and certificate or key management. Defenders should check claims, audience restrictions, signing keys and trust relationships.
• Conditional Access: Conditional access is a policy model that decides whether an action should proceed based on context such as posture, resource sensitivity, timing, and scope. For AI agents, it must be evaluated at request time so a valid credential does not automatically equal permitted behaviour.
• SAML: Security Assertion Markup Language is an XML-based federation protocol used to pass signed identity assertions between an identity provider and a relying party. It remains common in enterprise SSO, but its certificate-driven trust model can make configuration and rotation more operationally demanding.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.