Conditional Access Conditional Access

Bedingter Zugriff als Zero-Trust-Policy-Engine mit Signalen, Entscheidungen und Durchsetzung. Conditional Access as the Zero Trust policy engine built around signals, decisions, and enforcement.

Überblick Overview

Conditional Access (CA) ist die Richtlinien-Engine von Microsoft Entra ID. Sie wertet Identitäts-, Geräte-, Netzwerk-, Risiko- und Anwendungssignale aus und entscheidet dann, ob Zugriff erlaubt, eingeschränkt oder blockiert wird. Conditional Access (CA) is the policy engine of Microsoft Entra ID. It evaluates identity, device, network, risk, and application signals and then decides whether access is allowed, restricted, or blocked.

CA arbeitet nach dem Muster Wenn Zuweisung zutrifft → wende Kontrollen an. Die eigentliche Authentifizierung findet zuerst statt; Conditional Access greift danach in den Token- und Sitzungsfluss ein. CA follows the pattern If assignment matches → apply controls. Initial authentication happens first; Conditional Access then influences token and session behavior.

Signal → Entscheidung → Durchsetzung Signal → Decision → Enforcement

• Signal: Benutzer, Gruppe, Rolle, App, Gerät, Plattform, Standort, Clienttyp, Benutzer- oder Anmelderisiko.Signal: user, group, role, app, device, platform, location, client type, user risk, or sign-in risk.
• Entscheidung: Richtlinie trifft zu oder nicht. Mehrere Richtlinien werden kumulativ ausgewertet.Decision: policy applies or does not apply. Multiple policies are evaluated cumulatively.
• Durchsetzung: Blockieren, MFA, compliant device, Hybrid Join, App-Schutz, Authentication Strength oder Session Control.Enforcement: block, MFA, compliant device, hybrid join, app protection, authentication strength, or session control.

Wenn Ihr Tenant nur grundlegende Schutzmechanismen braucht und keine P1/P2-Lizenzen vorhanden sind, sind Security Defaults der Einstieg. Security Defaults und Conditional Access sollten nicht parallel eingesetzt werden. If your tenant only needs basic protection and no P1/P2 licenses are available, Security Defaults are the starting point. Security Defaults and Conditional Access should not be used in parallel.

Komponenten Components

Jede CA-Richtlinie besteht aus zwei großen Bausteinen: Assignments definieren, wann die Richtlinie gilt; Controls definieren, was dann passiert. Every CA policy has two major building blocks: assignments define when the policy applies; controls define what happens next.

Bewährtes Denkmuster Recommended thinking pattern

• Mit einer klaren Benutzerpopulation beginnen und Break-Glass-Konten konsequent ausschließen.Start with a clear user population and explicitly exclude break-glass accounts.
• Immer zuerst bestimmen, welches Geschäftsrisiko die Richtlinie abdeckt.Always define which business risk the policy addresses first.
• Policies möglichst konsolidieren, damit Auswertung und Betrieb verständlich bleiben.Consolidate policies where possible so evaluation and operations stay understandable.
• Neue Richtlinien zuerst im Modus Report-only testen.Test new policies in report-only mode first.

Zuweisungen Assignments

Assignments entscheiden, ob eine Richtlinie überhaupt evaluiert wird. Dazu gehören Benutzer und Gruppen, Cloud Apps oder Aktionen sowie optionale Bedingungen wie Standort, Gerät oder Risiko. Assignments determine whether a policy is evaluated at all. They include users and groups, cloud apps or actions, and optional conditions such as location, device, or risk.

Benutzer und Gruppen Users and groups

Ein häufiger Fehler ist, nur eine Allow-Policy für eine Teilmenge zu definieren. Benutzer außerhalb dieser Teilmenge erhalten dann eventuell trotzdem Tokens, wenn keine blockierende Gegenrichtlinie existiert. A common mistake is defining only an allow policy for a subset. Users outside that subset may still get tokens if no blocking counterpart policy exists.

Cloud Apps und Ressourcen Cloud apps and resources

Bedingungen Conditions

Device Filters sind besonders nützlich, wenn nur bestimmte Geräteserien, Kiosk-Devices oder Testgeräte vom Standard abweichen sollen. Sie ersetzen aber keine saubere Gerätegruppen- oder Compliance-Strategie. Device filters are especially useful when only certain device series, kiosk devices, or test devices should deviate from the standard. They do not replace a proper device group or compliance strategy.

Zugriffssteuerung Access controls

Grant Controls definieren, ob Zugriff blockiert oder unter einer oder mehreren Voraussetzungen gewährt wird. Wenn mehrere Policies gleichzeitig greifen, müssen alle resultierenden Anforderungen erfüllt sein. Grant controls define whether access is blocked or granted with one or more requirements. If multiple policies apply at the same time, all resulting requirements must be satisfied.

Require all vs. require one Require all vs. require one

• Require all selected controls: typischerweise für starke Admin-Policies, z. B. MFA und compliant device.Require all selected controls: typically for strong admin policies, for example MFA and compliant device.
• Require one of the selected controls: sinnvoll bei Übergangsszenarien, z. B. compliant device oder Hybrid Join.Require one of the selected controls: useful for transition scenarios, such as compliant device or hybrid join.
• Block Access hat immer Vorrang vor Grant-Optionen innerhalb derselben Richtlinie.Block access always takes precedence over grant options within the same policy.

Session Controls Session controls

Session Controls verändern das Verhalten nach erfolgreichem Zugriff. Sie sind besonders wichtig, wenn Sie Zugriff nicht komplett blockieren, aber die Nutzbarkeit einschränken möchten. Session controls change behavior after access has succeeded. They are especially important when you do not want to block access entirely but still want to restrict usability.

Named Locations Named locations

Named Locations sind wiederverwendbare Netzwerkdefinitionen. Sie können IP-basierte Standorte, Länder/Regionen oder GPS-basierte Länderprüfungen für den Authenticator enthalten. Named locations are reusable network definitions. They can represent IP-based locations, countries/regions, or GPS-based country checks through Authenticator.

PowerShell: IP-Standort erstellen PowerShell: create IP location

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess","Policy.Read.All"

$params = @{
    "@odata.type" = "#microsoft.graph.ipNamedLocation"
    displayName   = "HQ Berlin"
    isTrusted     = $true
    ipRanges      = @(
        @{
            "@odata.type" = "#microsoft.graph.iPv4CidrRange"
            cidrAddress   = "203.0.113.0/24"
        },
        @{
            "@odata.type" = "#microsoft.graph.iPv6CidrRange"
            cidrAddress   = "2001:db8:100::/48"
        }
    )
}

New-MgIdentityConditionalAccessNamedLocation -BodyParameter $params
Get-MgIdentityConditionalAccessNamedLocation

Graph: Country-Standort erstellen Graph: create country location

POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/namedLocations
Content-Type: application/json

{
  "@odata.type": "#microsoft.graph.countryNamedLocation",
  "displayName": "Blocked Countries",
  "countriesAndRegions": [
    "RU",
    "BY",
    "KP"
  ],
  "countryLookupMethod": "clientIpAddress",
  "includeUnknownCountriesAndRegions": false
}

Trusted Named Locations verbessern zusätzlich die Genauigkeit von Identity Protection. Sie sollten aber nur echte, kontrollierte Unternehmensnetze markieren und keine beliebigen ISP- oder VPN-Bereiche. Trusted named locations also improve Identity Protection accuracy. Only mark real, controlled corporate networks as trusted—never arbitrary ISP or VPN ranges.

Authentication Strengths Authentication strengths

Authentication Strengths verfeinern die klassische MFA-Anforderung. Statt nur zu sagen MFA erforderlich, legen Sie fest, welche Methoden oder Methodenkombinationen akzeptiert werden. Authentication strengths refine the classic MFA requirement. Instead of merely saying MFA required, you specify which methods or method combinations are acceptable.

• Custom Strengths sind ideal, wenn SMS/Voice ausdrücklich ausgeschlossen werden sollen, obwohl allgemeine MFA weiterhin erlaubt ist.Custom strengths are ideal when SMS and voice should be explicitly excluded while general MFA remains allowed elsewhere.
• Für sehr privilegierte Konten sollten Sie built-in oder custom phishing-resistant Varianten einsetzen.For highly privileged accounts you should use built-in or custom phishing-resistant variants.
• Die zugrunde liegenden Methoden müssen zuvor in der Authentication Methods Policy aktiviert und den Zielgruppen zugewiesen sein.The underlying methods must first be enabled and targeted in the authentication methods policy.

Report-only Report-only

Mit Report-only simulieren Sie eine Richtlinie produktionsnah, ohne Benutzer aktiv zu blockieren oder herauszufordern. Das ist die wichtigste Betriebsfunktion für sichere Einführungen. With report-only you simulate a policy in a production-like manner without actively blocking or challenging users. It is the most important operational feature for safe introductions.

• Neue Policies zunächst Report-only und nur mit Pilotgruppen testen.Roll out new policies in report-only first and test only with pilot groups.
• Im Sign-in Log die Policy-Auswertung auf Report-only und Would have succeeded/failed prüfen.In the sign-in log inspect the policy evaluation for report-only and would have succeeded/failed.
• Bei Konflikten zuerst Zuweisungen und Exclusions bereinigen, nicht sofort zusätzliche Gegenrichtlinien bauen.If conflicts appear, clean up assignments and exclusions first instead of immediately building counter-policies.

What-If What-If

Das What-If-Tool zeigt, welche Richtlinien für einen bestimmten Benutzer, eine App, einen Standort oder ein Gerät voraussichtlich greifen würden. Es ist das schnellste Portalwerkzeug für Hypothesen-Tests. The What-If tool shows which policies would likely apply to a specific user, app, location, or device. It is the fastest portal tool for testing hypotheses.

Das Tool ist stark für Design und Fehlersuche, ersetzt aber keine echten Sign-in Logs. Einige dynamische Faktoren, abhängige Apps oder Zwischenschritte einer Authentifizierung werden im realen Sign-In vollständiger sichtbar. The tool is excellent for design and troubleshooting, but it does not replace real sign-in logs. Some dynamic factors, dependent apps, or intermediate authentication steps become more visible in a real sign-in.

Empfohlene Richtlinien Recommended baseline

Die folgenden sechs Richtlinien decken einen praxistauglichen Microsoft-Baseline-Ansatz ab. Reihenfolge und Ausnahmen müssen an Ihren Tenant angepasst werden, aber die Grundidee ist in vielen Umgebungen tragfähig. The following six policies provide a practical Microsoft-style baseline. Sequence and exceptions must be adapted to your tenant, but the overall design is workable in many environments.

1. Legacy Authentication blockieren 1. Block legacy authentication

2. Phishing-resistant MFA für Administratoren 2. Phishing-resistant MFA for administrators

3. MFA für alle Benutzer bei allen Cloud Apps 3. MFA for all users on all cloud apps

4. Compliant Device für Admin-Zugriff 4. Compliant device for admin access

5. Hohes Anmelderisiko blockieren 5. Block high sign-in risk

6. Mobile BYOD nur mit App Protection 6. Mobile BYOD with app protection only

PowerShell & Graph PowerShell & Graph

Für Automation sollten Sie Richtlinien definitionsbasiert verwalten. Speichern Sie JSON-Vorlagen im Repository und behandeln Sie CA-Änderungen wie Code mit Review, Test und Rollback. For automation you should manage policies based on definitions. Store JSON templates in the repository and treat CA changes like code with review, testing, and rollback.

PowerShell CRUD PowerShell CRUD

Connect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.ConditionalAccess","Directory.Read.All"

# CREATE
$newPolicy = @{
    displayName = "CA - Require MFA for All Users"
    state       = "enabledForReportingButNotEnforced"
    conditions  = @{
        users = @{
            includeUsers = @("All")
            excludeUsers = @("breakglass@contoso.com")
        }
        applications = @{
            includeApplications = @("All")
        }
        clientAppTypes = @("all")
    }
    grantControls = @{
        operator        = "OR"
        builtInControls = @("mfa")
    }
}

$policy = New-MgIdentityConditionalAccessPolicy -BodyParameter $newPolicy

# READ
Get-MgIdentityConditionalAccessPolicy
Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policy.Id

# UPDATE
$update = @{
    state = "enabled"
}
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policy.Id -BodyParameter $update

# DELETE
Remove-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policy.Id

Vollständiges Graph-JSON Full Graph JSON

POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies
Content-Type: application/json

{
  "displayName": "CA - Block legacy auth",
  "state": "enabled",
  "conditions": {
    "users": {
      "includeUsers": [
        "All"
      ],
      "excludeUsers": [
        "11111111-1111-1111-1111-111111111111"
      ]
    },
    "applications": {
      "includeApplications": [
        "All"
      ]
    },
    "clientAppTypes": [
      "exchangeActiveSync",
      "other"
    ]
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": [
      "block"
    ]
  }
}

Graph per REST aktualisieren Update by Graph REST

PATCH https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/{policy-id}
Content-Type: application/json

{
  "state": "enabledForReportingButNotEnforced"
}

DELETE https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/{policy-id}

GET https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies
GET https://graph.microsoft.com/v1.0/identity/conditionalAccess/namedLocations

Troubleshooting Troubleshooting

Fast jede CA-Fehlersuche beginnt im Sign-in Log. Prüfen Sie dort den Reiter Conditional Access, die Device Details, die verwendete App-ID, den Clienttyp und den angewendeten Netzwerkstandort. Almost every CA troubleshooting exercise starts in sign-in logs. Check the Conditional Access tab, device details, the app ID in use, the client type, and the evaluated network location.

Limits Limits

Für das Richtliniendesign sollte ein konservativer Betriebsgrenzwert von 195 Conditional-Access-Policies eingeplant werden. Unabhängig von serviceinternen Änderungen ist diese Grenze ein guter Governance-Wert, weil Richtlinien sonst schnell unübersichtlich und fehleranfällig werden. For policy design, use a conservative operational ceiling of 195 Conditional Access policies. Regardless of backend service changes, this is a good governance limit because policies otherwise become difficult to understand and error-prone.

• Policies nach Szenario statt nach Einzelfall strukturieren.Organize policies by scenario instead of by one-off exception.
• Filter for applications und Gruppenlogik nutzen, um Anzahl zu reduzieren.Use application filters and group logic to reduce the count.
• Doppelte Ausnahmen beseitigen und Alt-Policies regelmäßig archivieren.Remove duplicated exceptions and archive old policies regularly.
• Named Locations, Authentication Strengths und Intune-Compliance wiederverwenden, statt immer neue Policies zu erzeugen.Reuse named locations, authentication strengths, and Intune compliance instead of creating new policies all the time.

Komplette Cloud-App-IDs und AliasesComplete cloud app IDs and aliases

Die folgende Referenz kombiniert harte App-IDs, eingebaute Conditional-Access-Aliases und typische App-Familien. Für produktive Policies gilt: Was immer möglich ist, zuerst im Sign-in Log oder an der Enterprise App des eigenen Tenants validieren – insbesondere bei Adminportalen, Power Platform, Viva und anderen First-Party-Portalen.The following reference combines hard app IDs, built-in Conditional Access aliases, and common app families. For production policies, validate the target in sign-in logs or the tenant's Enterprise App whenever possible—especially for admin portals, Power Platform, Viva, and other first-party portals.

Connect-MgGraph -Scopes "Application.Read.All"

Get-MgServicePrincipal -Filter "appId eq 'cc15fd57-2c6c-4117-a88c-83b1d56b4bbe'"
Get-MgServicePrincipal -Search ""displayName:Microsoft Teams"" -ConsistencyLevel eventual
Get-MgAuditLogSignIn -Top 5 | Select-Object AppDisplayName, ResourceDisplayName, AppId

Vollständige CA-Policy-JSON-ReferenzComplete CA policy JSON reference

Graph-Requests für Conditional Access bestehen im Kern aus Top-Level-Metadaten, Conditions, Grant Controls und Session Controls. Die Felder unterscheiden sich je nach API-Version leicht; die folgende Vorlage deckt die v1.0-relevanten Kernfelder inklusive deviceFilter, Authentication Strengths, App-Filter und Session Controls ab.Graph requests for Conditional Access primarily consist of top-level metadata, conditions, grant controls, and session controls. Field names vary slightly by API version; the following template covers the core v1.0-relevant fields including deviceFilter, authentication strengths, application filters, and session controls.

{
  "displayName": "CA - Admins - Phishing resistant MFA",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "users": {
      "includeUsers": [],
      "excludeUsers": ["11111111-1111-1111-1111-111111111111"],
      "includeGroups": [],
      "excludeGroups": [],
      "includeRoles": ["62e90394-69f5-4237-9190-012177145e10"],
      "excludeRoles": [],
      "includeGuestsOrExternalUsers": {
        "guestOrExternalUserTypes": "none",
        "externalTenants": { "membershipKind": "all" }
      }
    },
    "applications": {
      "includeApplications": ["797f4846-ba00-4fd7-ba43-dac1f8f63013", "00000003-0000-0000-c000-000000000000", "Microsoft_Admin_Portals"],
      "excludeApplications": [],
      "includeUserActions": [],
      "includeAuthenticationContextClassReferences": [],
      "applicationFilter": {
        "mode": "include",
        "rule": "servicePrincipal.displayName -startsWith "Microsoft""
      }
    },
    "clientAppTypes": ["browser", "mobileAppsAndDesktopClients"],
    "locations": { "includeLocations": ["All"], "excludeLocations": ["trusted-named-location-id"] },
    "platforms": { "includePlatforms": ["all"], "excludePlatforms": [] },
    "signInRiskLevels": ["low", "medium", "high"],
    "userRiskLevels": ["high"],
    "servicePrincipalRiskLevels": ["high"],
    "devices": {
      "deviceFilter": {
        "mode": "exclude",
        "rule": "device.extensionAttribute1 -eq "BreakGlassDevice""
      }
    }
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": ["mfa", "compliantDevice"],
    "customAuthenticationFactors": [],
    "termsOfUse": [],
    "authenticationStrength": {
      "id": "00000000-0000-0000-0000-000000000004",
      "displayName": "Phishing-resistant MFA"
    }
  },
  "sessionControls": {
    "applicationEnforcedRestrictions": { "isEnabled": false },
    "cloudAppSecurity": { "isEnabled": false, "cloudAppSecurityType": "monitorOnly" },
    "persistentBrowser": { "isEnabled": true, "mode": "never" },
    "signInFrequency": {
      "isEnabled": true,
      "type": "hours",
      "value": 4,
      "authenticationType": "primaryAndSecondaryAuthentication",
      "frequencyInterval": "timeBased"
    },
    "continuousAccessEvaluation": { "mode": "strictLocation" },
    "secureSignInSession": { "isEnabled": true, "mode": "compliantDevice" },
    "disableResilienceDefaults": false
  }
}

Device-Filter-Syntax vollständigComplete device-filter syntax reference

Device Filters verwenden eine PowerShell-ähnliche Ausdruckssprache und werden immer gegen Geräteeigenschaften ausgewertet, die dem Sign-in zur Verfügung stehen. Sie sind stark für Kiosk-, Pilot-, Branch- oder Ausnahmeszenarien – aber sie sind kein Ersatz für Compliance Policies, Join-Modelle oder gute Gerätegruppen.Device filters use a PowerShell-like expression language and are evaluated against device properties available to the sign-in. They are powerful for kiosk, pilot, branch, or exception scenarios—but they are not a replacement for compliance policies, join models, or sound device grouping.

device.trustType -in ["AzureAD","ServerAD"] and
(device.physicalIds -any (_ -contains "[OrderID]:Kiosk")) and
(device.extensionAttribute1 -ne "ExcludeFromCA")

Token Protection (Preview)Token protection (preview)

Token Protection bindet ausgegebene Tokens enger an das Gerät, auf dem die primäre Authentifizierung stattgefunden hat. Ziel ist es, gestohlene oder von einem Adversary-in-the-Middle-Proxy abgefangene Tokens auf einem fremden Gerät unbrauchbar zu machen oder ihre Wiederverwendbarkeit stark einzuschränken.Token protection binds issued tokens more tightly to the device where primary authentication occurred. The goal is to make stolen or adversary-in-the-middle-captured tokens unusable—or far less reusable—on a different device.

• Mit verwalteten Windows-Geräten und privilegierten Benutzergruppen pilotieren.Pilot with managed Windows devices and privileged user groups.
• Immer parallel Sign-in Logs, Device Claims und Helpdesk-Signale beobachten.Always watch sign-in logs, device claims, and helpdesk signals in parallel.
• Token Protection mit phishing-resistant MFA und PIM kombinieren, nicht isoliert betrachten.Combine token protection with phishing-resistant MFA and PIM instead of viewing it in isolation.

Continuous Access EvaluationContinuous Access Evaluation

Continuous Access Evaluation (CAE) verkürzt die Zeit zwischen einem sicherheitsrelevanten Ereignis und der tatsächlichen Durchsetzung. Statt auf klassische Tokenablaufzeiten zu warten, können unterstützte Clients und Dienste auf kritische Änderungen nahezu in Echtzeit reagieren.Continuous Access Evaluation (CAE) shortens the time between a security-relevant event and actual enforcement. Instead of waiting for classic token expirations, supported clients and services can react to critical changes almost in real time.

• CAE ist kein Ersatz für Conditional Access, sondern beschleunigt dessen Durchsetzung.CAE is not a replacement for Conditional Access; it accelerates enforcement.
• Strict Location Enforcement ist besonders relevant, wenn Netzwechsel oder Global Secure Access im Spiel sind.Strict location enforcement is especially relevant when network changes or Global Secure Access are involved.
• Legacy Auth und ältere Clients profitieren typischerweise nicht von CAE – genau dort bleiben klassische Block-Policies wichtig.Legacy auth and older clients typically do not benefit from CAE—this is exactly where classic block policies remain important.