Treat the app as an exception that needs compensating controls, not as a reason to accept weaker login behaviour. Restrict access paths where possible, remove redundant credentials, and document the residual exposure so the application cannot silently undermine the broader identity programme.
When an app cannot meet the preferred login policy
When an application cannot support the preferred authentication policy, the right response is to contain the exception rather than weaken the standard for everything else. That usually means limiting who can reach the app, reducing the credentials it can rely on, and making the exception visible in governance so the app does not become a silent weak spot in the identity estate.
That distinction matters because authentication weaknesses are often easiest to exploit at the boundary where older apps, vendor portals, or legacy protocols are left untouched. A controlled exception can be acceptable; an undocumented one creates a second, weaker login path that attackers and insiders will gravitate toward.
What a controlled exception should look like
A controlled exception should start with a decision about access, not convenience. If the app cannot support the preferred policy, restrict it to the smallest feasible user group, the smallest feasible network path, and the smallest feasible set of sign-in methods that still preserve operational use. In practice, that may mean fronting the app with an identity layer, blocking direct access, or removing redundant local accounts where a federated path already exists.
The aim is to preserve the broader authentication standard while isolating the exception from normal traffic. If the application supports neither strong authentication nor a better federation pattern, organisations should treat the app as a higher-risk dependency and avoid letting it define the bar for adjacent systems. This is especially important when the app holds privileged data or can reach other internal resources.
Where the application supports only weaker mechanisms, the compensating control set should be explicit and minimal. That can include time-bounded approval, tighter session limits, stronger monitoring, and documented ownership for exception review. The key point is that the exception should be engineered, not simply tolerated.
How to keep one weak app from weakening the whole identity programme
The common failure mode is scope creep. One legacy application cannot support the preferred policy, then a second team asks for the same treatment, and soon the exception becomes a shadow standard. That is how organisations end up with a formally strong authentication policy and a practically inconsistent one.
To avoid that drift, the exception record should capture the residual exposure in plain terms: what login behaviour remains weaker, which users are affected, what compensating controls exist, and what would trigger review or retirement. The app should also be revisited on a defined cycle so the exception does not persist long after a workable upgrade path exists. For broader identity governance, NIST SP 800-63 Digital Identity Guidelines gives a useful reference point for sign-in assurance expectations, while stronger access boundaries and least-privilege design can be reinforced with NIST Cybersecurity Framework 2.0.
There is also a practical evidence problem. If teams cannot show who approved the exception, what compensating controls were applied, and when the application will be reassessed, the exception is not really managed. It is merely deferred risk. Organisations should be able to explain why the app was allowed to diverge and why that divergence does not extend beyond the approved scope.
Risk and Threat Considerations
An app that cannot meet the preferred authentication policy becomes an attractive target if it offers a weaker route into a trusted environment. Attackers look for exactly these seams, because they often bypass stronger controls elsewhere and can provide a foothold for account abuse, session theft, or lateral movement.
Failure mechanism: The app preserves an alternate login path, local credential store, or weaker session model that is easier to phish, reuse, relay, or steal than the organisation’s standard authentication flow.
Impact: The exception can expand blast radius beyond the app itself, undermine trust in the identity programme, and create a durable path into systems that would otherwise require stronger sign-in assurance. If the app reaches sensitive data or administrative functions, the residual exposure is materially higher.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | 3 — Digital Identity Guidelines | Sets identity assurance expectations for apps that cannot meet the preferred login policy. |
| Recommendation — Map the app to the lowest acceptable AAL and require compensating controls before granting access. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Applies because the app exception changes how authentication and access are enforced. |
| Recommendation — Restrict the app to the smallest viable access path and enforce the strongest available authentication. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Relevant because the app exception must be governed as an access-control deviation. |
| A.8.5 — Secure authentication | Applies when the app cannot support the preferred authentication method. | |
| Recommendation — Document the exception, limit access, and review it on a defined cadence. Apply compensating authentication controls and remove redundant weaker login options. | ||
| OWASP ASVS | V6 — Authentication | Directly fits an application that cannot meet the preferred authentication policy. |
| Recommendation — Verify that the app’s remaining authentication flow is bounded and cannot silently weaken enterprise standards. | ||
Practitioner Guidance
What to prioritise: Decide first whether the app truly needs direct user access or whether it can be placed behind a stronger access path, such as federation, network restriction, or an intermediary control that removes the weakest login method from the user journey.
What to verify: Verify that the exception does not reintroduce duplicate accounts, unmanaged local passwords, or unrestricted direct login paths. If the app still authenticates users locally, confirm who owns those credentials and how they are rotated, reviewed, and retired.
Decision rule: If the app can authenticate users only with weaker behaviour, treat that as an exception requiring compensating controls and expiry, not as a permanent policy downgrade.
Practitioner takeaway: The real control objective is consistency of assurance, so any app that cannot match the preferred policy must be isolated, documented, and actively governed until it can be brought back into the standard model.