Notifications
Clear all
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.
NHIMG editorial — based on content published by Zluri: What is conditional access?
Questions worth separating out
Q: How should security teams implement conditional access without overcomplicating access decisions?
A: Start with a small set of high-value conditions such as device compliance, location, and application sensitivity.
Q: Why do conditional access policies fail when device telemetry is weak?
A: Because the policy is only as trustworthy as the signal feeding it.
Q: What do security teams get wrong about conditional access and MFA?
A: They often treat MFA and conditional access as interchangeable.
Practitioner guidance
- Define high-risk access conditions first Start with unmanaged devices, unfamiliar locations, and sensitive applications, then map those scenarios to allow, block, or step-up responses.
- Validate device telemetry before enforcement Confirm that your device posture feed reflects real compliance status, not stale inventory data.
- Review exception paths on a fixed cadence Track every bypass, break-glass rule, and temporary exemption, then remove or re-justify them through access review.
What's in the full article
Zluri's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step policy configuration examples for device, location, and risk-based rules
- Platform-specific setup guidance for applying conditional access across SaaS applications
- Examples of adaptive remediation actions and reporting workflows
- Administrator-oriented implementation detail for balancing usability and enforcement
👉 Read Zluri's guide to conditional access and contextual identity controls →
Conditional access for IAM teams: are your controls keeping up?
Explore further
12/06/2026 10:55 pm
Conditional access is a governance layer, not a substitute for identity discipline. The article describes a control that evaluates context before access is granted, which is useful, but the security value still depends on how well identities, devices, and resources are governed upstream. If access policy is built on weak account hygiene or stale device signals, the control is only masking structural problems. Practitioners should treat conditional access as an enforcement layer that exposes programme maturity, not as proof of it.
A few things that frame the scale:
- From our research: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Our research also shows that only 5.7% of organisations have full visibility into their service accounts, which makes contextual access decisions harder to trust.
A question worth separating out:
Q: Who should be accountable for conditional access policy drift?
A: IAM, security architecture, and application owners should share accountability, because drift usually comes from policy exceptions, changing business requirements, and inconsistent signal quality. Governance works when someone owns the review cycle, the exception register, and the evidence that rules still match the risk they were meant to control.
👉 Read our full editorial: Conditional access exposes the limits of password-only identity security
