Topic starter
12/06/2026 9:04 pm
TL;DR: Conditional access uses signals such as user identity, device health, location, and risk to decide whether access should be granted, step up authentication, or be blocked, according to Zluri. The control matters because it turns identity decisions into context-aware policy enforcement, but it still depends on how well teams define and maintain those conditions.
Editorial analysis by NHI Mgmt Group, based on content published by Zluri: “What is Conditional Access?”.
Key questions
Q: How should security teams implement conditional access in SaaS environments?
A: Start by tying access decisions to identity, device posture, location, and resource sensitivity, then define when step-up authentication or denial should occur.
Q: When does conditional access create more friction than security value?
A: Conditional access becomes counterproductive when policies are too rigid, poorly matched to user context, or applied without a clear exception model.
Q: What are the best practices for keeping conditional access policies current?
A: Review policies after major changes in application portfolio, device estate, remote work patterns, or risk tolerance.
Practitioner guidance
- Define access conditions by risk tier Map user identity, device compliance, location, and resource sensitivity into explicit policy tiers so the decision logic is testable and repeatable.
- Require step-up authentication for higher-risk sessions Use stronger verification when users connect from unmanaged devices, unfamiliar geographies, or suspicious sign-in patterns rather than applying one static rule to all sessions.
- Review policy exceptions and stale conditions Search for long-lived exceptions, overbroad trusted locations, and outdated device rules that no longer reflect actual access risk.
Bottom line: Password-only access decisions are too weak for environments where device posture, location, and sign-in risk all change the trust level of a session.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
12/06/2026 10:55 pm
Password strength is not an access policy: Conditional access exists because authentication alone does not answer whether a session is trustworthy. Once teams accept that a valid login can still be a risky login, identity governance shifts from proving who signed in to deciding whether the current context deserves access. The practitioner conclusion is that passwords are only one input to authorisation, never the whole control.
A question worth separating out:
Q: What should IAM teams prioritise after passwordless becomes the default direction?
A: Prioritise recovery design, interoperability standards, and lifecycle governance. Passwordless changes the authentication surface, but it does not remove identity lifecycle risk. Teams that succeed will treat authentication as one part of a broader trust system covering enrolment, reauthentication, recovery, and revocation across the full user journey.
👉 Read our full editorial: Conditional access exposes the limits of password-only identity security
This post was modified 6 days ago by NHI Mgmt Group