Conditional Access

Conditional Access regulates access based on conditions like user, device, location, and risk. The term originates from Microsoft Entra ID, but other identity providers offer the same principle.

How it works

During each sign-in, the IdP evaluates a set of rules. For example, one rule might require MFA for anyone signing in from outside Switzerland. Another might only permit access to financial data from managed devices. If the risk is high, such as a password from a known data breach, access can be blocked or a password change enforced.

A practical example: a rule requires a managed laptop and phishing-resistant MFA for admin portals. An attacker has a stolen admin password and tries to sign in from their own device. Access is denied, and the SOC receives an Alert about the failed attempt.

What to look out for

• Start with simple rules for all users, like requiring MFA and blocking legacy protocols.
• Test new policies in report-only mode first so that no one gets locked out.
• Keep any exceptions small, documented, and for a limited time.
• Protect emergency accounts and monitor every one of their sign-ins.
• Review the rules regularly, as contradictions and gaps can accumulate over the years.

Typical mistakes

A common mistake is creating broad exceptions for entire locations or networks. Attackers who are already inside the network can take advantage of these. A second mistake involves rules that only apply to a few applications. New applications then remain unprotected until someone remembers to add them.

Relevance for the SOC

Conditional Access logs show which rules were triggered and which sign-ins were blocked. They are an important source of information for the SOC. Alerts on changes to the rules themselves are also important, as attackers often try to weaken them.

How we implement it

We monitor sign-ins and changes to Conditional Access rules in our SOC. We are happy to discuss architecture questions as part of our Security Consulting.