Why do risky sign-ins, legacy authentication, and non-compliant devices increase the need for Conditional Access?

These conditions weaken trust at the exact moment access is being requested. Risky sign-ins may indicate the identity owner is not in control, legacy protocols cannot enforce MFA, and non-compliant devices may already be exposed or unmanaged. Conditional Access reduces that risk by requiring stronger verification, blocking unsafe paths, or limiting access when signals look suspicious.

Why This Matters for Security Teams

conditional access is doing more than “adding friction.” It is the control point that decides whether a request deserves trust at all. Risky sign-ins, legacy authentication, and non-compliant devices each weaken the confidence security teams can place in the requester, the protocol, or the endpoint. That matters because access decisions made too early, or with too little context, are hard to unwind after data has already been reached. Current guidance suggests pairing access controls with device posture, sign-in risk, and authentication method checks rather than treating any one signal as sufficient.

For teams managing identities at scale, this is especially important because weaknesses often cluster. A device that is not compliant may also be unmanaged, a legacy auth flow may bypass stronger verification, and a risky sign-in may indicate token theft or compromised credentials. NHI Management Group’s research shows how quickly identity weaknesses become operational risk: 90% of IT leaders say properly managing NHIs is essential for zero-trust implementation, yet only 20% have formal offboarding and revocation processes in place in the Ultimate Guide to NHIs.

That same pattern appears in human access paths too, where defenders often discover the control gap only after a suspicious login has already been used to move laterally or retrieve sensitive data.

How It Works in Practice

Conditional Access works best when it evaluates multiple signals at the moment of access, not after the fact. A risky sign-in can trigger step-up authentication, a block, or a limited session. Legacy authentication can be denied outright because older protocols often cannot enforce modern checks like MFA or device compliance. Non-compliant devices can be restricted to a safer path, such as web-only access, quarantine, or no access until the device meets policy.

That model aligns with modern zero trust thinking: trust is not granted once and reused indefinitely. It is continuously re-evaluated based on identity, device posture, location, application sensitivity, and session risk. NIST’s NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both support this kind of risk-based, policy-driven access governance. The same logic is reflected in the Top 10 NHI Issues, where standing access, weak secret handling, and poor visibility make static trust decisions brittle.

• Use sign-in risk to decide whether the request needs MFA, approval, or outright denial.
• Block legacy authentication paths where possible, especially for internet-facing applications.
• Require device compliance for sensitive applications, not just for the directory login.
• Apply exception handling sparingly and time-bound it so bypasses do not become permanent.

This guidance breaks down in environments that still depend on legacy protocols for critical business apps, because those systems often cannot consume the signals Conditional Access needs to make a reliable decision.

Common Variations and Edge Cases

Tighter Conditional Access often increases helpdesk load, exception management, and rollout complexity, so organisations have to balance stronger control against user and operational friction. That tradeoff is real, especially when older applications, unmanaged contractors, or hybrid device fleets are in scope. Best practice is evolving, but the current direction is clear: treat exceptions as temporary risk acceptances, not alternative policy design.

Some environments also need different treatment for different identities. Privileged admins, developers, service accounts, and remote workers should not all face the same access path. A device that is “non-compliant” may still be acceptable for low-risk portals, while the same device should be blocked from finance, production, or administrative systems. Likewise, a risky sign-in from an unfamiliar location might be tolerable for a read-only session but not for password reset, token issuance, or data export.

For deeper context on how weak identity controls compound over time, the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the Ultimate Guide to NHIs — Key Challenges and Risks show why weak posture signals and stale trust assumptions become harder to correct over time.

There is no universal standard for exactly where to set every threshold, so security teams should tune Conditional Access by application sensitivity, user population, and tolerance for interruption rather than copying a single baseline across the enterprise.

Related resources from NHI Mgmt Group

• How should security teams manage access across employees, contractors, non-human identities, and IoT devices without creating new blind spots?
• Why do non-human identities increase zero trust risk?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should security teams use conditional access to block risky devices?