Because they only verify the entry point. Once the session is established, the application still has to decide what the identity can do, and static authorization leaves too much room for broad, persistent access. Zero Trust needs continuous decision-making inside the application layer, not just strong authentication at login.
Why MFA and SSO solve entry, not authorization
MFA and SSO are strong controls for proving who is entering the system, but they do not, by themselves, decide what that session is allowed to do after login. A zero trust programme has to assume the session can be abused, then continuously constrain actions, re-evaluate trust, and limit blast radius inside the application and resource layers.
That distinction matters because authentication and authorization are different control points. If the application still grants broad access based only on a valid session, then compromise, token theft, or overbroad role assignment can turn one successful login into persistent access across sensitive functions.
For practitioners, the key design question is not whether the login is strong, but whether every material action still requires a fresh policy decision. Identity Provider and SSO Security Guide is useful here because it frames SSO as one part of a larger control surface that also includes session security and federation trust.
Where static authorization falls short in Zero Trust
Static authorization usually means permissions are assigned once and then reused for the full life of the session. That is efficient, but it is also where Zero Trust programmes often weaken: a role, group, or scope can outlive the context that justified it, leaving users or services with access that is broader than the current task.
Zero Trust works better when authorization is contextual and bounded. That can mean step-up checks for sensitive functions, shorter session lifetimes for higher-risk actions, resource-level policy enforcement, or just-in-time access for privileged operations. The point is to keep access proportional to the current request, not the original login event.
For identity and access teams, this is where application design and policy design meet. IAM and Identity Provider Buyer's Guide helps frame the broader platform choice, but the deeper lesson is that platform features alone do not create Zero Trust unless the application consumes and enforces those decisions.
Zero Trust architectures formalise this idea by treating access as a continuous decision rather than a one-time grant. The application or gateway should verify the request context, not just the initial identity proof, which is why NIST SP 800-207 Zero Trust Architecture remains a useful reference for policy enforcement and least-privilege design.
What actually completes the model inside the application
To finish a Zero Trust programme, teams need controls that bind the session to the action. That usually includes fine-grained authorization, policy evaluation close to the resource, revalidation for high-impact changes, and logging that makes post-login decisions visible. The objective is to prevent a valid session from becoming an open-ended entitlement.
In practice, the strongest pattern is to separate identity proof from action approval. MFA can reduce account takeover risk, and SSO can reduce password sprawl, but neither one tells the business service whether a user may export records, approve payments, change entitlements, or reach an admin function. Those decisions belong in application logic and enforcement points that understand the operation being requested.
External identity standards reinforce this separation. NIST SP 800-63 Digital Identity Guidelines is relevant because it addresses authentication strength and assurance, while the actual authorization decision still has to be made by the application or resource layer.
When teams miss that boundary, they often mistake “logged in” for “trusted.” Zero Trust does the opposite: it accepts the login as necessary, then keeps asking whether the current request still deserves access.
Risk and Threat Considerations
The main risk is that a successful login becomes a durable foothold. If sessions are long-lived, permissions are broad, or tokens can be replayed, an attacker does not need to defeat MFA again to keep operating. That is why session theft, token theft, and overprivileged roles are such persistent failure modes in environments that stop at sign-in.
Failure mechanism: The system treats authentication as the final trust decision, then allows the same session or token to authorize sensitive actions without fresh context checks, allowing stolen or overbroad access to persist.
Impact: An attacker or misused account can move from initial access to data exposure, privilege abuse, and lateral impact with far less resistance than a Zero Trust design intends.
Credential and session abuse are recurring lessons in the field, which is why session-aware enforcement and token handling matter as much as login hardening. CitrixBleed exploitation 2023 is a reminder that valid session material can bypass the front door entirely once the session is established.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers session and credential handling after initial authentication. |
| AC-6 — Least Privilege | Directly supports limiting what a logged-in identity can do after SSO. | |
| IA-2 — Identification and Authentication (Organizational Users) | Applies to MFA and SSO as the login assurance layer being discussed. | |
| Recommendation — Rotate and manage authenticators so sessions and tokens do not become durable standing access. Enforce least privilege so authenticated users can only perform necessary actions. Strengthen user authentication, then pair it with downstream authorization controls. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The whole question concerns why login controls alone do not complete Zero Trust. |
| Recommendation — Place continuous policy checks at the resource and application layers, not just at sign-in. | ||
| OWASP ASVS | V8 — Authorization | The answer depends on enforcing what a session may do after authentication. |
| Recommendation — Design fine-grained authorization checks for every sensitive application action. | ||
Practitioner Guidance
What to prioritise: Put policy enforcement where the sensitive action occurs, not only at the login boundary. The first milestone should be a clear list of operations that must be re-authorized, step-up authenticated, or time-bounded because they carry material business or security impact.
What to verify: Confirm that high-risk functions are protected by resource-level checks, not just role membership. If a user or service can still perform a critical action with a stale session, broad scope, or inherited group access, the Zero Trust design is incomplete.
Common mistake: Treating SSO rollout as a finished security programme. SSO reduces authentication friction, but it can also centralise blast radius if the application layer does not enforce narrow, continuously evaluated permissions.
Practitioner takeaway: Zero Trust is completed by continuous authorization and session control, not by stronger sign-in alone. If the application cannot independently decide what the identity may do next, MFA and SSO have improved the front door without securing the rooms beyond it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org