Conditional access exposes the limits of password-only identity security

At a glance

What this is: This is a guide to conditional access, showing how access decisions can be based on identity, device posture, location, and risk instead of passwords alone.

Why it matters: It matters because IAM teams need controls that adapt to context across human access, service access, and broader identity governance, not just stronger login prompts.

Context

Conditional access is a policy layer that evaluates context before granting access. In this article, the core governance gap is that password-only identity security assumes authentication is enough, even when device health, location, and sign-in risk are changing.

That assumption fails in remote and SaaS-heavy environments because access decisions are no longer made once at login. For IAM teams, conditional access is the control that turns identity, device posture, and policy into an ongoing authorisation decision rather than a static gate.

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. The control works best when the policy reflects the real risk of each app and user group, rather than using one rule for every session. Regular review is essential because conditions change faster than most policies.

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. If trusted users are repeatedly blocked, or MFA prompts appear even for low-risk situations, adoption suffers. The best approach is to calibrate controls by group, device trust, and network location so verification stays proportionate.

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. Keep trusted locations, exemptions, and step-up thresholds under formal change control, and verify that logs show the policy actually fired as intended. The control degrades quickly when teams treat it as a one-time setup.

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.

Technical breakdown

How conditional access evaluates identity context

Conditional access evaluates access requests against policy conditions such as user identity, device compliance, location, and resource sensitivity. It can require stronger authentication, restrict access, or deny entry when the request falls outside policy. The mechanism matters because it separates possession of credentials from entitlement to the resource. In practice, that turns the identity provider into an enforcement point rather than just a login broker. The article frames this as a response to the weakness of password-only control, but the technical model is broader: context, not credentials alone, determines the result.

Practical implication: define the specific signals your access policies will trust, and treat each signal as an enforcement input rather than a reporting field.

Why device health and location change the access decision

Device health and location are high-value inputs because they change the risk profile of the same user and the same password. A compliant device inside a trusted network presents a different assurance level from an unmanaged device used from an unfamiliar location. Conditional access uses those differences to apply step-up authentication or blocking before access is established. That is the key architectural shift: authorisation becomes conditional on the session context, not just the login event. The article also points to logging and reporting, which are necessary because the policy decision itself becomes part of the control evidence.

Practical implication: treat device posture and location as policy dimensions that must be validated, monitored, and periodically retested.

How adaptive policies support continuous access governance

Adaptive policies use changing risk signals to alter access decisions in real time. That allows organisations to increase friction when risk rises and reduce it when conditions remain acceptable. The governance value is not automation for its own sake, but repeatable enforcement across many apps and access paths. For identity teams, this is where conditional access moves from a convenience feature to a lifecycle control: policies must be updated as applications, user groups, devices, and risk appetite change. Without that maintenance, policy drift creates gaps that look secure on paper but fail in operation.

Practical implication: review conditional access rules as living governance assets, not one-time configuration work.

Threat narrative

Attacker objective: The attacker wants to turn valid credentials into unrestricted access to sensitive resources by bypassing context-aware controls.

1. Entry occurs when an attacker uses valid credentials against an environment that still trusts passwords as the main access factor.
2. Escalation follows when the same login is accepted from an untrusted device or unusual location because policy conditions are too weak or incomplete.
3. Impact is broader access to applications and data that should have been limited by step-up authentication or denial.

Breaches seen in the wild

• New York Times GitHub breach 2024: An exposed GitHub token gave an attacker The New York Times' repositories; the 270GB leak held 4,875 unique secrets.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Conditional access is a governance control, not just an authentication control: The article correctly ties access decisions to device health, location, and risk signals. That means IAM teams must maintain policy logic with the same discipline they apply to roles and entitlements. The practitioner conclusion is that access policy drift can become as dangerous as permission drift.

Context-aware access is where human IAM and NHI governance converge: The same operating principle applies when a person, service account, or automated workflow is the requester. If policy only checks credential possession, it misses the difference between a managed user session and a machine or remote session with weaker assurance. The practitioner conclusion is to govern the access decision, not just the identity type.

Named concept: access-context drift. Conditional access fails when the conditions that justified access at design time no longer match the conditions present at runtime. That drift can come from unmanaged devices, stale risk scores, or policy exceptions that accumulate over time. The practitioner conclusion is that condition quality must be managed as carefully as identity quality.

Audit evidence must come from decision records, not policy intent: Logging and reporting matter because auditors and security teams need to see which conditions were evaluated and what action was taken. A policy that exists but is not observable is hard to defend and harder to tune. The practitioner conclusion is that access decision logs are part of the control, not an afterthought.

What this signals

Access-context drift: The main governance risk is not conditional access itself, but the way policy conditions decay after they are written. Over time, exceptions, stale trusted locations, and outdated device rules create a gap between intended enforcement and actual enforcement, which is where access programmes lose credibility.

For identity teams, the practical lesson is that conditional access must be treated like a living control surface. Policies should be reviewed alongside role changes, device estate changes, and application onboarding so that the access decision still reflects the current risk model.

For practitioners

• 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.
• Verify logging for access decisions Confirm that each allow, deny, or step-up decision is recorded with the evaluated conditions so security teams can audit and tune policy behaviour.

Key takeaways

• 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.
• Conditional access works by making the access decision conditional on context, not just on whether credentials are valid.
• The control only remains effective when policy conditions, exceptions, and logging are continuously maintained.

Key terms

• 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.
• Step-up Authentication: Step-up authentication is an additional verification step triggered when a session becomes higher risk or a user attempts a sensitive action. It is used to reduce exposure without forcing extra friction across every interaction, which makes it useful for runtime access governance.
• Device Compliance Enforcement: Device compliance enforcement is the process of blocking or limiting access when an endpoint no longer meets required data handling rules. It goes beyond detection, using technical controls to prevent continued access until the user fixes the issue. This is essential when sensitive data moves onto employee-managed devices.
• Access Decision Logging: The recording of what conditions were evaluated, what policy fired, and what outcome was taken for each access request. It gives security teams evidence for audit, tuning, and incident review, and it is essential when access rules are adaptive or context aware.

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.