What do teams get wrong about Conditional Access and legacy protocols?

Why This Matters for Security Teams

conditional access is often treated as a universal safeguard, but that assumption breaks the moment legacy authentication protocols remain enabled. Modern policy engines can evaluate browser sign-ins, device state, and MFA prompts, yet older protocols may authenticate outside that layer entirely. That gap matters because attackers do not need to defeat the whole identity stack if one protocol still accepts basic credentials. The result is a policy coverage problem, not just a password hygiene problem. This is especially dangerous in mixed environments where Exchange, SMTP, IMAP, POP, or older service integrations still exist for business convenience. Teams may believe they have enforced strong sign-in controls because the modern portal shows MFA and risk-based prompts, while legacy paths continue to accept credentials without those checks. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which means any bypass path can become a high-impact foothold when credentials are reused across services. The practical issue is that security intent is not the same as protocol enforcement. In practice, many security teams encounter legacy protocol abuse only after mailbox abuse, token theft, or impossible travel alerts have already occurred, rather than through intentional policy validation.

How It Works in Practice

The right way to assess Conditional Access is to map it by sign-in protocol and authentication flow, not by policy name alone. Modern identity providers can enforce Conditional Access on interactive sign-ins, but legacy protocols may authenticate through separate endpoints or older auth mechanisms that never evaluate the same controls. That is why current guidance from the OWASP Non-Human Identity Top 10 aligns with protocol-level visibility: if a flow can bypass the policy engine, it must be treated as a separate attack surface. Practically, teams should:

• Inventory every protocol in use, including mail and service protocols, and confirm whether Conditional Access applies to each one.
• Disable legacy authentication wherever business dependencies allow it, especially for accounts that do not need interactive access.
• Separate human and non-human access paths so service accounts and automation do not inherit human sign-in assumptions.
• Validate MFA enforcement against actual protocol traces, not just policy configuration screens.
• Review logs for basic auth, older client usage, and repeated sign-in attempts that never trigger modern prompts.

This is not only a human-user problem. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks highlights how broad NHI exposure and overprivilege compound the blast radius when an attacker lands on a credential that bypasses policy. A stolen secret used over a legacy protocol can succeed even when the organisation believes MFA is “on.” These controls tend to break down in hybrid mail environments and older SaaS integrations because protocol exceptions are often left in place for compatibility while the policy team assumes global enforcement is still active.

Common Variations and Edge Cases

Tighter protocol lockdown often increases operational overhead, requiring organisations to balance authentication hardening against application compatibility and helpdesk load. That tradeoff is real, but current best practice is evolving toward disabling legacy paths by default and restoring only the minimum necessary exceptions. Some environments have genuine exceptions. Multi-function devices, older mail clients, and embedded systems may still rely on basic authentication or non-interactive flows. The mistake is to treat those exceptions as harmless because they are “internal” or “low risk.” If the account behind the integration has mailbox access, API scope, or directory privileges, a bypassed protocol becomes a direct intrusion path. The 52 NHI Breaches Analysis reinforces a consistent pattern: weak governance around credential use and access paths is what turns a small exception into a major incident. For this reason, teams should distinguish between:

• Protocol exceptions that are temporary and documented
• Long-lived legacy access that should be retired
• Service accounts that must be re-architected into modern auth

There is no universal standard for every legacy edge case, but the operational rule is simple: if a protocol cannot participate in modern policy evaluation, it should not be assumed to benefit from Conditional Access. That distinction is often missed until attackers exploit the quiet path no one included in the original rollout.

Related resources from NHI Mgmt Group

• What do security teams get wrong about conditional access and authentication strength?
• What do identity teams get wrong about phishing-resistant controls?
• What do teams get wrong about safe login risk scores?
• What do teams get wrong about AI security and access management?