Skip to content

Portal Walkthrough — Control 1.11: Entra Conditional Access and Phishing-Resistant MFA for AI Agents

Control: 1.11 — Conditional Access and Phishing-Resistant MFA Pillar: 1 — Security Last UI Verified: April 2026 (Microsoft Entra admin center, Microsoft Defender portal, Power Platform admin center, Copilot Studio) Estimated Time: 14–22 hours of admin effort across 5–7 calendar days (includes the mandatory 7-day Report-only soak window) Governance Levels: Baseline / Recommended / Regulated Audience: Entra Global Admin, Entra Security Admin, Authentication Policy Admin, Power Platform Admin, AI Administrator, Sentinel Admin, Purview Compliance Admin, CISO, Compliance Officer, Agent Owner, Agent Maker Companion playbooks: ./powershell-setup.md · ./verification-testing.md · ./troubleshooting.md · ./conditional-access-agent-templates.md

Scope Limit — what this control IS and IS NOT

Control 1.11 is an identity-plane access control. It governs who (or what) can sign in to surfaces that produce, host, administer, or invoke Microsoft 365 AI agents and how strongly that sign-in is authenticated. It is preventive — it blocks an unauthorized session at the front door.

It is not an evidentiary, supervisory, content-quality, or model-risk control. Specifically, this playbook does not replace:

Adjacent concern Owning control
Supervisory review of agent outputs (FINRA Rule 3110, registered principal sign-off) Control 2.12 — Supervision and Oversight under FINRA Rule 3110
DLP policies, environment strategy, connector classification for Power Platform / Copilot Studio Control 2.2 — Environment Groups and Tier Classification
Model risk management framework (OCC 2011-12 / Fed SR 11-7 alignment) Control 2.6 — Model Risk Management Alignment with OCC 2011-12 / SR 11-7
Agent publishing authorization, maker entitlement gating Control 1.1 — Restrict Agent Publishing by Authorization
Lifecycle for ownerless agents and orphan remediation Control 3.6 — Orphaned Agent Detection and Remediation
Agent inventory, governance dashboards, admin-gated approvals Control 2.25 — Microsoft Agent 365 Admin Center Governance Console
SIEM ingestion, KQL analytics, sign-in correlation rules Control 3.9 — Microsoft Sentinel Integration

A configured Conditional Access (CA) policy that blocks an unauthorized session does not generate the supervisory record that FINRA Rule 3110 requires for the content of an agent interaction; that record is produced by the controls listed above. Treat 1.11 as a necessary but not sufficient layer.

Human vs Agent identity — two distinct MFA boundaries

Two identity types touch agent surfaces, and they must be governed by different mechanisms:

Identity type Examples How MFA works Conditional Access path
Human (interactive) identity Agent maker, agent owner, Power Platform Admin, AI Administrator, end-user invoking a Copilot agent in Teams Interactive MFA prompt — passkey, FIDO2 security key, Windows Hello for Business, Microsoft Authenticator (push + number match) Standard CA policy targeting Users and groups
Agent / workload identity Service principal that runs a Copilot Studio agent, managed identity for an autonomous agent, Entra Agent ID preview registration, third-party connector app Cannot perform interactive MFA (no human at the keyboard). Governed by certificate-based auth, managed identity, secret rotation, and Conditional Access for Workload Identities (CA-WID) which evaluates location, sign-in risk, and named locations instead of MFA strength CA policy with Users and workload identities → Workload identities selected (requires the Microsoft Entra Workload Identities Premium P1 add-on licensed per service principal in scope)

"MFA the agent" is a category error. Strong agent-identity governance means (a) issuing the agent a non-shared credential (managed identity preferred, then certificate, then secret with mandatory ≤90-day rotation), (b) scoping it via CA-WID to permitted IP ranges and risk thresholds, and (c) monitoring its sign-ins separately from human sign-ins. See §7 for the workload-identity path.

Hedged-Language Reminder

The procedures here support compliance with and help meet the following expectations; they do not by themselves satisfy any obligation, and configuration is necessary but not sufficient:

  • FFIEC — Authentication and Access to Financial Institution Services and Systems (June 2021 update to the 2005 Authentication in an Internet Banking Environment guidance) — risk-based, layered authentication for high-risk transactions and administrative access
  • NYDFS 23 NYCRR Part 500 §500.12 — Multi-Factor Authentication; the Second Amendment (effective Nov 1, 2024 / Nov 1, 2025) requires MFA for any individual accessing the covered entity's information systems, with Class A companies expected to adopt phishing-resistant authentication for privileged accounts
  • SEC Regulation S-P — Safeguards Rule and Disposal Rule (May 2024 amendments) — written policies and procedures reasonably designed to safeguard customer information, with 30-day customer-notification timeline on unauthorized access
  • FINRA Regulatory Notice 21-18 — Cybersecurity practices, supervision of access control changes
  • NIST SP 800-63B — Authenticator Assurance Levels; AAL2 (multi-factor) and AAL3 (hardware-bound, verifier-impersonation-resistant) — phishing-resistant authenticators (FIDO2, passkeys, Windows Hello for Business, smart cards) map to AAL3
  • CISA Zero Trust Maturity Model v2.0 — Identity pillar Optimal stage (continuous, phishing-resistant authentication; centralized identity store; just-in-time access)
  • OCC Bulletin 2011-12 / Federal Reserve SR 11-7 — Model risk management; the supervisory expectation that monitoring of model performance and access extends to AI agents that materially influence customer or financial outcomes
  • CFTC Rule 1.31 / 17 CFR §1.31 — recordkeeping; sign-in logs and CA policy-change records must be retained in a non-rewritable, non-erasable form

Implementation requires validated change-control procedures, a periodic access review (Control 2.5), and independent testing. Organizations should verify all configurations against examiner workpapers and counsel.

Surface inventory — portals you will touch in this playbook

# Surface URL Owner role
1 Microsoft Entra admin center https://entra.microsoft.com Authentication Policy Admin, Entra Security Admin
2 Microsoft Defender portal (Sentinel + Identity) https://security.microsoft.com Sentinel Admin
3 Power Platform admin center https://admin.powerplatform.microsoft.com Power Platform Admin
4 Copilot Studio https://copilotstudio.microsoft.com Agent Maker, AI Administrator
5 Microsoft 365 admin center (license validation) https://admin.microsoft.com Entra Global Admin
6 Microsoft Agent 365 Admin Center (governance console) https://admin.microsoft.com → Agent 365 AI Administrator (cross-ref Control 2.25)

Document Map

§ Section Outcome
0 Pre-flight prerequisites and license validation Confirm SKUs, roles, network position, and break-glass posture before any change
1 Migrate Security Defaults to a Conditional Access baseline Tenant has CA-driven baseline, not Security Defaults
2 Authentication Methods policy — passwordless-first baseline FIDO2, WHfB, Passkeys enabled; SMS/voice deprecated for privileged roles
3 Authentication Strengths — create the "Phishing-Resistant MFA" strength Reusable strength object bound to CA policies
4 Named Locations — corporate IP ranges and country allow-list Trusted IP envelopes for human and workload policies
5 Policy A — Phishing-resistant MFA for all privileged roles Privileged role activations require AAL3-class authenticator
6 Policy B — Agent makers require compliant device + phishing-resistant MFA Copilot Studio / Power Platform maker access fenced to compliant devices
7 Policy C — Conditional Access for Workload Identities (agents and SPs) Agent identities scoped to named locations and risk thresholds
8 Policy D — Session controls: CAE, sign-in frequency, Token Protection Continuous evaluation, 4-hour reauth in Z3, token binding pilot
9 Entra Agent ID — locating agent identities and assigning them to CA Agent identities discoverable in Workload identities blade and bound to Policy C
10 Privileged Identity Management — activation-time MFA for AI / privileged roles PIM eligibility with on-activation phishing-resistant MFA
11 Sentinel Conditional Access Insights workbook Daily / weekly impact dashboard wired to the Control 3.9 workspace
12 Break-glass / emergency access accounts Two cloud-only accounts excluded from CA, monitored by analytic rule
13 Report-only to Enforce rollout — the 7-day soak Documented rollout with sign-in log review
14 Sovereign cloud parity — GCC, GCC High, DoD Documented unavailability and substitute posture
15 Evidence pack and verification cross-references Examiner-ready artifact list

0. Pre-flight prerequisites and license validation

Before changing anything in production, complete every gate below. Skipping a gate is the most common cause of a CA rollout that locks administrators out of the tenant.

0.1 Confirm administrative roles assigned via PIM (eligible, not active)

Sign in to https://entra.microsoft.com with an account that already holds Entra Global Admin in the tenant. Browse to Identity governance → Privileged Identity Management → Microsoft Entra roles → Assignments. Filter to Eligible assignments.

Confirm the roles below are present and assigned only to named individuals (not shared service accounts). Use the canonical role names from docs/reference/role-catalog.md — if your tenant displays the legacy long-form name, that is the same role.

Canonical role Required for Minimum count
Entra Global Admin Migrating Security Defaults, creating tenant-wide CA policies 2 (plus 2 break-glass — see §12)
Authentication Policy Admin Authentication Methods policy, Authentication Strengths 2
Conditional Access Admin (Microsoft built-in role) Creating and editing CA policies 2
Entra Security Admin Reviewing risky users, managing Identity Protection 2
Power Platform Admin Validating that Policy B does not break Copilot Studio 1+
AI Administrator Reviewing agent identities (Entra Agent ID preview) and Agent 365 console 1+
Sentinel Admin Wiring the CA Insights workbook in §11 1

Do not use 'Administrator' as a role name

The canonical short name is Authentication Policy Admin, not "Authentication Policy Administrator". The Entra portal still displays the long form; the role is identical. The same applies to Power Platform Admin (not "Power Apps Admin"), Exchange Online Admin (not "Exchange Administrator"), and Purview Compliance Admin (not "Compliance Administrator"). Use the short forms in all internal documentation, change tickets, and WSPs to avoid drift.

0.2 Validate license entitlements

Open https://admin.microsoft.com → Billing → Licenses. Confirm the SKUs below before promoting any policy past Report-only.

SKU Required for Minimum count
Microsoft Entra ID P1 Conditional Access for human users; Authentication Strengths All licensed users in any CA policy scope
Microsoft Entra ID P2 Identity Protection risk policies, PIM, risky-user CA conditions All privileged-role holders
Microsoft Entra Workload Identities Premium (P1 add-on) Conditional Access for Workload Identities (CA-WID) One per service principal, managed identity, or Entra Agent ID identity in CA-WID scope
Microsoft 365 E5 or Microsoft 365 E3 + Entra ID P2 Token Protection (Preview), Continuous Access Evaluation Privileged users, Z3 environment users
Microsoft Defender for Cloud Apps (optional) Session controls beyond CAE (cloud app reverse proxy) As scoped
Microsoft Sentinel §11 workbook and analytic rules Tenant-level

CA-WID without the P1 add-on fails open

A Conditional Access policy that targets a workload identity without a Microsoft Entra Workload Identities Premium license assigned to that identity will not enforce — the policy simply does not evaluate. There is no in-portal warning for this. The only safe verification is to (a) attempt a deliberate denial scenario (block by named location) from outside the trusted IP range and (b) inspect the Sign-in logs (Service principal sign-ins tab) for the conditionalAccessStatus field. A notApplied status with the policy in scope is the symptom. See ./troubleshooting.md issue T-07.

0.3 Sovereign cloud determination — stop here if applicable

Inspect your authentication endpoint. If your admin URL is admin.microsoft.us or you authenticate against login.microsoftonline.us, jump to §14 for the GCC / GCC High / DoD parity table before proceeding. Several Policy C / Policy D capabilities (CA for Workload Identities, Token Protection Preview, device-bound passkeys synced via Microsoft Authenticator) have a lagging release schedule in sovereign clouds and must be documented as product unavailability, not as a tenant policy exception.

0.4 Confirm break-glass accounts already exist

Two cloud-only *.onmicrosoft.com emergency-access accounts must exist before any CA policy is enabled. If they do not, complete §12 first, then return here. The single most common source of tenant lockout is enabling a CA policy that targets "All users" without confirming the break-glass accounts are excluded.

0.5 Document the change in your CAB record

Open the change ticket and reference (a) this playbook revision, (b) the target Authentication Strength name, (c) the four CA policy names you will create, (d) the 7-day Report-only window dates, and (e) the planned cutover date. Attach the empty Evidence Pack folder structure from §15.

1. Migrate Security Defaults to a Conditional Access baseline

If your tenant still has Security Defaults turned on, you cannot create granular CA policies. Security Defaults is an all-or-nothing tenant-wide MFA enforcement that conflicts with policy-based access control. The migration path is well documented and one-way.

1.1 Determine current state

  1. Browse to https://entra.microsoft.com → Identity → Overview → Properties (the Properties tab on the tenant overview blade).
  2. Scroll to Security defaults. Note whether it reads Enabled or Disabled.

1.2 If Security Defaults is enabled — disable only after CA baseline is staged

Do not disable Security Defaults until you have at least one CA policy in Report-only that requires MFA for privileged roles (the policy you will create in §5). The recommended order is:

  1. Stage Policy A from §5 in Report-only.
  2. Confirm break-glass accounts exist and are excluded (§12).
  3. Return to Properties → Security defaults and click Manage security defaults.
  4. Toggle Security defaults to Disabled.
  5. Select My organization is using Conditional Access as the reason.

  6. Click Save.

  7. Within 5 minutes, enable Policy A by switching it from Report-only to On (after the soak period defined in §13). Until that switch, the tenant is in a temporary reduced-MFA state — schedule the cutover to occur during a maintenance window with monitoring eyes-on.

Migration is not reversible without re-enabling Security Defaults

Once disabled, your tenant relies entirely on the CA policies you have authored. There is no automatic re-application of the Microsoft baseline if you delete all your CA policies. Microsoft Managed Policies (the Source = Microsoft baseline templates) provide some safety net, but they do not replicate Security Defaults coverage. Treat this as a one-way door.

2. Authentication Methods policy — passwordless-first baseline

The Authentication Methods policy controls what authenticators users may register and use. It is distinct from Conditional Access (which decides whether an authentication is acceptable for a given resource). You must enable the strong methods here before you can require them in a CA policy.

2.1 Navigate to the Authentication Methods policy

  1. https://entra.microsoft.com → Protection → Authentication methods → Policies.

The blade lists every method (FIDO2, Microsoft Authenticator, Passkey (FIDO2), Windows Hello for Business, Certificate-based authentication, OATH tokens, SMS, Voice call, Email OTP, Temporary Access Pass, Hardware OATH tokens, QR Code (Preview), Third-party software OATH tokens). Each row shows Enabled, Target, and Last modified.

2.2 Enable FIDO2 security keys

  1. Click FIDO2 security key in the methods list.
  2. Toggle Enable to On.
  3. Under Target, select All users (or a pilot group during phased rollout — see §13).
  4. Expand Configure and set:
  5. Allow self-service set up: Yes
  6. Enforce attestation: Yes (rejects keys that cannot prove their cryptographic provenance)
  7. Enforce key restrictions: Yes
  8. Restrict specific keys: Allow — populate with the AAGUIDs of approved enterprise keys (YubiKey 5 series, Feitian ePass, Token2 PIN+ — get the AAGUIDs from the vendor)
  9. Click Save.

AAGUID allow-list is mandatory for FSI

Allowing any FIDO2 key (no allow-list) accepts consumer-grade keys that may not meet your firm's HSM or attestation expectations. The AAGUID allow-list is the only gate between your tenant and a $20 unattested key bought online. Maintain the list in a versioned configuration repo and review it quarterly.

2.3 Enable Passkeys (Microsoft Authenticator)

A passkey stored in the Microsoft Authenticator app is a phishing-resistant authenticator that satisfies the same CA requirement as a hardware FIDO2 key. It is appropriate for end-users and lower-risk admin scenarios; device-bound hardware FIDO2 keys remain the recommendation for top-tier privileged roles (Entra Global Admin, Authentication Policy Admin).

  1. In the methods list, click Passkey (FIDO2).
  2. Toggle Enable to On.
  3. Under Target, select All users.
  4. Under Configure:
  5. Allow self-service set up: Yes
  6. Enforce attestation: Yes
  7. Enforce key restrictions: Yes — include the Microsoft Authenticator passkey AAGUID (90a3ccdf-635c-4729-a248-9b709135078f for iOS Authenticator; de1e552d-db1d-4423-a619-566b625cdc84 for Android Authenticator — verify current AAGUIDs in Microsoft Learn before deployment).
  8. Click Save.

2.4 Enable Windows Hello for Business

  1. Click Windows Hello for Business.
  2. Toggle Enable to On.
  3. Target: All users (the Authentication Methods policy enables registration; the deployment of Windows Hello on the endpoint is governed by Intune / Group Policy and is out of scope for this playbook).
  4. Click Save.

2.5 Configure Microsoft Authenticator (push + number match)

  1. Click Microsoft Authenticator.
  2. Toggle Enable to On.
  3. Under Configure:
  4. Authentication mode: Any (allows both push and passwordless sign-in)
  5. Require number matching for push notifications: Enabled for All users
  6. Show application name in push and passwordless notifications: Enabled
  7. Show geographic location in push and passwordless notifications: Enabled
  8. Click Save.

Number matching has been mandatory since February 27, 2023

Microsoft made number matching the default for all Authenticator push notifications in February 2023. The toggle in this blade lets you confirm enforcement and lock additional context (app name, location). It does not need to be re-enabled, but the setting should be auditable.

2.6 Deprecate SMS and voice for privileged roles

SMS and voice-call OTP are not phishing-resistant. They satisfy NIST AAL2 only when no out-of-band restricted channel (RESTRICTED_USE) condition applies, and they are explicitly disrecommended for privileged accounts under CISA, NIST SP 800-63B-4 (Initial Public Draft, August 2024 / second draft 2025), and NYDFS Class A guidance.

The recommended Entra pattern is not to disable SMS / voice tenant-wide (which would lock out users still mid-migration), but to exclude privileged-role groups from SMS / voice targets while leaving them available for general user fallback.

  1. In the methods list, click SMS.
  2. Toggle Enable to On (or leave on if already enabled).
  3. Under Target, click Add groups, select All users, then click Exclude and add the group Privileged-Role-Holders (a security group that contains every PIM-eligible privileged-role holder; create this group in Identity → Groups → All groups → New group if it does not exist).
  4. Repeat for Voice call.

Group membership must stay synchronized with PIM eligibility

The Privileged-Role-Holders group is the linchpin of this exclusion. If a new user is granted Entra Global Admin eligibility but is not added to the group, they retain SMS as a valid authenticator and the phishing-resistance posture is silently broken. Automate group membership via the PowerShell job in ./powershell-setup.md section "Sync PIM eligibility to security group" and run it on a 1-hour schedule. The verification test is in ./verification-testing.md test case VT-04.

2.7 Configure the registration campaign

The registration campaign nudges users with weaker authenticators to register a stronger one (specifically Microsoft Authenticator) at sign-in.

  1. https://entra.microsoft.com → Protection → Authentication methods → Registration campaign.
  2. Set State to Microsoft managed (recommended) or Enabled.
  3. Set Days allowed to snooze to 0 for the privileged-role group (forced registration) and 14 for general users.
  4. Click Save.

2.8 Propagation note

Authentication Methods policy changes can take up to 24 hours to fully propagate across all Microsoft authentication endpoints. Document the change time in the CAB ticket and do not rely on a strong method in a CA policy until the soak window described in §13 has elapsed.

3. Authentication Strengths — create the "Phishing-Resistant MFA" strength

An Authentication Strength is a named, reusable bundle of accepted authentication method combinations that you reference from a CA grant control. Microsoft ships three built-in strengths (Multifactor authentication, Passwordless MFA, Phishing-resistant MFA). Most FSI organizations define a custom strength in addition, to express their AAGUID allow-list and to forbid combinations that the built-in strength permits but that the firm's WSP does not.

3.1 Inspect the built-in strengths

  1. https://entra.microsoft.com → Protection → Conditional Access → Authentication strengths.
  2. The default tab Built-in lists the three Microsoft strengths. Click Phishing-resistant MFA and review the accepted combinations:
  3. Windows Hello for Business
  4. Passkey (FIDO2)
  5. FIDO2 security key
  6. Certificate-based authentication (multi-factor)

The built-in Phishing-resistant MFA strength is acceptable for most uses. Skip §3.2 and §3.3 if your firm has no AAGUID-restriction or method-exclusion requirement.

3.2 Create a custom "FSI Phishing-Resistant MFA" strength

  1. On the Authentication strengths blade, click the Custom authentication strengths tab → + New authentication strength.
  2. Name: FSI Phishing-Resistant MFA
  3. Description: AAL3-class authenticator. AAGUID-restricted to enterprise-issued FIDO2 keys (YubiKey 5, Feitian ePass) and Authenticator passkeys. Required for privileged roles, agent makers in Z3, and Agent 365 Admin Center access. Owner: CISO. Cross-ref: Control 1.11.
  4. Authentication method combinations: check
  5. FIDO2 security key
  6. Passkey (FIDO2) (Microsoft Authenticator)
  7. Windows Hello for Business
  8. Click Next.
  9. On the FIDO2 security key advanced settings page, select Allow specific keys and paste the AAGUIDs from §2.2.
  10. On the Passkey (FIDO2) advanced settings page, select Allow specific keys and paste the Authenticator passkey AAGUIDs from §2.3.
  11. Click Review + Create, then Create.

3.3 Confirm the strength is selectable from a CA policy

  1. https://entra.microsoft.com → Protection → Conditional Access → Policies → + New policy.
  2. Under Grant, click Grant access and check Require authentication strength.
  3. Confirm the FSI Phishing-Resistant MFA entry appears in the dropdown next to the three built-in strengths.
  4. Click Cancel (do not save the empty test policy).

4. Named Locations — corporate IP ranges and country allow-list

Named locations are reusable IP and country expressions referenced from CA conditions. You will need at least three:

Named location Type Purpose
Corporate IP Ranges - Trusted IPv4/IPv6 CIDR, Mark as trusted Office egress IPs; backbone for Policy B
Permitted Countries - Operations Country Country allow-list for human users (US, plus contracted offshore countries)
Workload Identity Permitted IPs IPv4/IPv6 CIDR, Do not mark as trusted Egress IPs from your Azure / on-prem services that host agents; backbone for Policy C

4.1 Create the trusted corporate IP location

  1. https://entra.microsoft.com → Protection → Conditional Access → Named locations → + IP ranges location.
  2. Name: Corporate IP Ranges - Trusted
  3. Add each office egress CIDR (/32 for single IPs is acceptable; /24 or wider preferred for branch ranges).
  4. Check Mark as trusted location.
  5. Click Create.

4.2 Create the permitted countries location

  1. + Countries location.
  2. Name: Permitted Countries - Operations
  3. Determine location by: IP address (the default; Authenticator GPS is available but should only be used for high-assurance scenarios because it relies on the user having Authenticator with location enabled).
  4. Select the country list. Most US FSI organizations include United States plus a small number of explicitly contracted offshore-development countries (India, Philippines, Ireland, etc.).
  5. Click Create.

4.3 Create the workload identity permitted IPs location

  1. + IP ranges location.
  2. Name: Workload Identity Permitted IPs
  3. Add the egress IPs of (a) your Azure subscriptions hosting Copilot Studio bot endpoints and connected services, (b) your on-premises ExpressRoute / hybrid services that host agent code, and (c) any approved third-party SaaS that calls Microsoft Graph or Dataverse on behalf of an agent.
  4. Do not check Mark as trusted (workload identities should not benefit from "trusted" location bypasses that may be added to other policies).
  5. Click Create.

IPv6 considered

Microsoft Graph and Dataverse increasingly accept IPv6 client connections. If your egress is dual-stack, include IPv6 CIDRs alongside IPv4. Missing IPv6 ranges produces intermittent CA-WID denials that are very hard to diagnose. See ./troubleshooting.md issue T-12.

5. Policy A — Phishing-resistant MFA for all privileged roles

This policy forces AAL3-class authentication at every sign-in (and at PIM activation) for any user holding a privileged Entra role, and for any user activating a PIM-eligible role. It is the foundation of NYDFS Class A §500.12 alignment for FSI.

5.1 Create Policy A in Report-only

  1. https://entra.microsoft.com → Protection → Conditional Access → Policies → + New policy.
  2. Name: CA-001 — All users — require phishing-resistant MFA for privileged roles
  3. Assignments → Users:
  4. Include: Directory roles — select every privileged role:
    • Entra Global Admin
    • Privileged Role Admin
    • Privileged Authentication Admin
    • Conditional Access Admin
    • Authentication Policy Admin
    • Authentication Admin
    • Security Admin
    • Exchange Admin
    • SharePoint Admin
    • Teams Admin
    • Power Platform Admin
    • Application Admin
    • Cloud Application Admin
    • User Admin
    • Helpdesk Admin
    • Compliance Admin
    • Compliance Data Admin
    • Information Protection Admin
    • AI Administrator (Microsoft built-in role added 2025)
    • Intune Admin
    • Hybrid Identity Admin
  5. Exclude: the Break-Glass-Accounts group (you create this in §12) and any service account group that is governed under Policy C instead.
  6. Target resources → Cloud apps: All cloud apps.
  7. Conditions: leave at default (no client app, device platform, or location filters — the policy must apply everywhere).
  8. Grant → Grant access:
  9. Check Require authentication strength → select FSI Phishing-Resistant MFA (or built-in Phishing-resistant MFA if you skipped §3.2).
  10. Check Require device to be marked as compliant (optional — enable only if your privileged-role holders all have managed devices; for mixed BYOD environments, omit and lean on §6).
  11. For multiple controls: Require all the selected controls.
  12. Session: leave default (CAE handled in Policy D).
  13. Enable policy: Report-only.
  14. Click Create.

5.2 Validate Report-only impact

After 24–48 hours of Report-only operation, browse to Identity → Monitoring & health → Sign-in logs → Conditional Access tab. Filter by Conditional Access policy = CA-001 and Result = Report-only: Failure. Each failure represents a sign-in that would have been blocked if the policy were live. Investigate every failure:

  • Was it a privileged-role holder using a non-phishing-resistant authenticator? Their account needs a passkey or hardware key registered (route them through §2.3 self-service setup).
  • Was it a service account that should have been excluded? Add to the exclusion group.
  • Was it a break-glass account that was accidentally not excluded? Stop the rollout immediately and fix the exclusion.

The decision criterion to flip Policy A from Report-only to On is documented in §13.

6. Policy B — Agent makers require compliant device + phishing-resistant MFA

This policy fences Copilot Studio, Power Platform, and Microsoft 365 Copilot agent-authoring surfaces to (a) users on Intune-compliant devices (b) authenticating with a phishing-resistant strength. It is the human-side complement to the workload-identity policy in §7.

6.1 Identify the cloud app targets

The relevant cloud apps as enumerated in the Entra cloud-app picker are:

Cloud app (display name in Entra) App ID Role in agent authoring
Power Apps 475226c6-020e-4fb2-8a90-7a972cbfc1d4 Power Apps maker portal
Power Automate 7df0a125-d3be-4c96-aa54-591f83ff541c Flow authoring
Microsoft Power Platform 1c75d0a8-3cd3-4a38-a5b8-e1c8b9e3ae3f (verify in your tenant) PPAC and consolidated Power Platform admin actions
Microsoft Copilot Studio 38e57f90-7c72-44e9-95a1-04f2f2a3a1f9 (verify in your tenant — Copilot Studio app ID has shifted as the product was renamed from Power Virtual Agents) Copilot Studio maker portal
Common Data Service (Dataverse) 00000007-0000-0000-c000-000000000000 Dataverse data plane that agents read/write

Verify app IDs in your tenant before saving the policy

The friendly names in the Entra cloud-app picker are stable; the GUIDs above may differ slightly between tenants depending on whether the app is enterprise-app-installed or first-party. To confirm a GUID, browse to Identity → Applications → Enterprise applications → All applications, search by name, and read the Application ID column. Copy the friendly names from the picker rather than typing GUIDs into the CA policy form.

6.2 Create Policy B in Report-only

  1. + New policy.
  2. Name: CA-002 — Agent makers — compliant device + phishing-resistant MFA for Copilot Studio / Power Platform
  3. Assignments → Users:
  4. Include: the security group Agent-Makers-All (a group containing every user with maker entitlement; populate from the source-of-truth defined in Control 1.1).
  5. Exclude: Break-Glass-Accounts, plus any developer who has a documented exception for a legacy ALM workflow (review quarterly).
  6. Target resources → Cloud apps → Include → Select apps: select the apps from the table in §6.1.
  7. Conditions:
  8. Device platforms → Include → Any device (default).
  9. Locations — leave at default to apply globally (the goal is to fence makers regardless of network position; do not exempt Trusted IPs, because a maker on a kiosk in the trusted office is still a maker).
  10. Grant → Grant access:
  11. Require authentication strength → FSI Phishing-Resistant MFA.
  12. Require device to be marked as compliant.
  13. For multiple controls: Require all the selected controls.
  14. Session: leave default (Policy D will add session controls).
  15. Enable policy: Report-only.
  16. Click Create.

6.3 Add Microsoft Agent 365 Admin Center to the same fence

The Agent 365 Admin Center governance console — see Control 2.25 — is reached through https://admin.microsoft.com → Agent 365. Access is gated by the Microsoft 365 admin center cloud app. To extend Policy B to cover this surface, clone Policy B as CA-002b and change the Users scope to:

  • Include: AI-Administrators group (members of the AI Administrator role) and Agent-365-Approvers group.
  • Cloud apps: Microsoft 365 admin center + Microsoft Graph (do not target "All cloud apps" because that would impact every M365 admin sign-in unrelated to Agent 365).

This gives you two narrowly-scoped policies (CA-002 for makers, CA-002b for governance-console operators) instead of one broad policy that is hard to roll back.

7. Policy C — Conditional Access for Workload Identities (agents and SPs)

This policy is the agent-identity boundary. It targets service principals (including the synthetic service principals that back Entra Agent ID preview registrations) and applies location and risk conditions. There is no MFA grant control for workload identities — workload identities cannot present a second factor to a human-style challenge. The grant control is block based on context.

7.1 Confirm the Workload Identities Premium SKU

Before creating the policy, re-verify §0.2: each service principal you intend to scope must have a Microsoft Entra Workload Identities Premium license. To check assignments:

  1. https://entra.microsoft.com → Identity → Applications → Enterprise applications → All applications.
  2. Locate the service principal (filter by application type Application and search by name).
  3. Open the SP, go to Properties, and look for Workload Identities Premium licensed: Yes/No.

If the field reads No, the policy will not enforce against this SP. Acquire the license SKU through https://admin.microsoft.com → Billing → Purchase services before continuing.

7.2 Create Policy C in Report-only

  1. https://entra.microsoft.com → Protection → Conditional Access → Policies → + New policy.
  2. Name: CA-003 — Workload identities — block agent SPs from non-permitted IPs and high risk
  3. Assignments → Users and workload identities:
  4. Switch the Users and workload identities dropdown to Workload identities.
  5. Include → Select service principals: add (a) every service principal that backs a Copilot Studio agent published to Z3, (b) every Entra Agent ID preview registration in Z3 (see §9), (c) any third-party application that has Graph or Dataverse permissions consented at admin level and is invoked on behalf of an agent.

  6. Exclude: Microsoft-first-party service principals required for tenant operations (do not include service principals owned by Microsoft Services or with publisher domain microsoft.com unless you have a specific reason).

  7. Target resources → Cloud apps → Include → All cloud apps.

  8. Conditions:
  9. Service principal risk (Preview) — Configure: Yes — Include risk levels: High, Medium (review weekly; tune based on Identity Protection signal quality).
  10. Locations — Configure: Yes — Include: Any location, Exclude: Workload Identity Permitted IPs (the named location from §4.3). The pattern is "block when not in the permitted IP set", expressed as include-all-locations-minus-exclude-permitted.
  11. Grant: Block access. Workload identities receive a Block grant (no MFA option exists for SPs).
  12. Session: not applicable for workload identities.
  13. Enable policy: Report-only.
  14. Click Create.

7.3 Validate Report-only impact for SPs

The Sign-in logs blade has a separate tab for service principal sign-ins.

  1. Identity → Monitoring & health → Sign-in logs.
  2. Click the Service principal sign-ins tab (next to User sign-ins).
  3. Filter Conditional Access = Report-only: Failure and Conditional Access policy = CA-003.
  4. Each row is a service principal sign-in that would have been blocked. For each, confirm:
  5. Is the source IP one that should be in the permitted set? Add it to Workload Identity Permitted IPs (§4.3).
  6. Is this an unexpected service principal (compromised credential, shadow integration)? Disable the SP and open an incident — see Control 3.9 for the analytic rule.

Don't apply CA-WID to managed identities you cannot test

A managed identity used by an Azure Function that posts to Microsoft Graph from a public Azure egress IP that you have not enumerated in §4.3 will be blocked the moment Policy C goes from Report-only to On. The 7-day soak window in §13 exists for exactly this reason. Plan to add IP ranges as you discover them and to extend the soak by another week if the Report-only failure rate has not stabilized.

8. Policy D — Session controls: CAE, sign-in frequency, Token Protection

The fourth policy adds session-layer controls. Unlike Policies A–C, Policy D does not block; it shortens session lifetimes and subscribes the token to revocation events so that if a credential or device posture changes mid-session, the session ends.

8.1 Continuous Access Evaluation (CAE)

CAE is enabled by default at tenant level for all CAE-aware Microsoft services (Exchange Online, SharePoint Online, Teams, Microsoft Graph). You verify it is on; you do not need to enable it per policy.

  1. https://entra.microsoft.com → Protection → Conditional Access → Policies → + New policy.
  2. Name: CA-004 — Session controls — CAE, sign-in frequency, Token Protection (Z3 environments)
  3. Assignments → Users: include Agent-Makers-Z3 (makers in Zone 3 environments) and Privileged-Role-Holders; exclude Break-Glass-Accounts.
  4. Target resources → Cloud apps → All cloud apps.
  5. Session:
  6. Check Customize continuous access evaluation → Strict enforcement (the strict mode revokes tokens within ~5 minutes of a critical event such as account disable, password change, or risky-user elevation; default mode allows up to 60 minutes).

8.2 Sign-in frequency — 4-hour reauth in Z3

Sign-in frequency forces an interactive reauthentication after the configured interval. For Z3 (Enterprise / regulated) environments, 4 hours is the recommended FSI baseline; for Z2 (Team), 8 hours; Z1 (Personal) inherits tenant default (typically 90 days for non-privileged users).

  1. In the same Policy D form, under Session:
  2. Check Sign-in frequency → Periodic reauthentication → 4 Hours.

8.3 Persistent browser — Never persistent for makers

  1. Check Persistent browser session → Never persistent.

This blocks "Stay signed in?" prompts in browser sessions on shared / unmanaged endpoints, ensuring the 4-hour reauth actually bites.

8.4 Token Protection (Preview) — Windows pilot

Token Protection binds a sign-in token to a specific Windows device's TPM, defeating token-replay attacks. It is in Preview as of April 2026, supports Windows 10 / 11 (no macOS, no Linux, limited mobile), and applies only to Exchange Online and SharePoint Online at preview.

For a pilot, create a separate policy CA-005 rather than co-mingling with Policy D, because the Token Protection scope is narrower than CA-004.

  1. + New policy → Name: CA-005 — Token Protection (Preview) — Windows pilot for privileged users.
  2. Users → Include: Privileged-Role-Holders-Pilot (a 5–20 user pilot subgroup); Exclude: Break-Glass-Accounts.
  3. Cloud apps → Include: Office 365 Exchange Online and Office 365 SharePoint Online (only the apps Token Protection currently supports).
  4. Conditions → Device platforms → Include: Windows only.
  5. Session → Require token protection for sign-in sessions (Preview): Enabled.
  6. Enable policy: Report-only.
  7. Click Create.

Token Protection breaks unsupported clients silently

A user signing in from an unsupported platform (macOS, mobile, Linux) under a Token Protection-required policy will be blocked. Scope tightly during preview. Microsoft is expanding platform coverage; check Microsoft Learn before each promotion from pilot to general rollout.

9. Entra Agent ID — locating agent identities and assigning them to CA

Entra Agent ID is the directory-level identity for AI agents. As of April 2026 it is in Public Preview and gated by the Microsoft Frontier program for many tenants. Where the preview is enabled, agent identities appear in two places in the Entra portal — and you need to know both.

9.1 Where agent identities appear

Surface What you see When to use
Identity → Applications → Enterprise applications → All applications Each agent appears as a service principal with Application type = Agent (a new value introduced for the preview) When binding an agent to a CA-WID policy (§7), you select its SP from this list
Identity → Identity governance → Agent ID (Frontier-gated; may not appear in your tenant) The agent registry — sponsor (human owner of record), custom security attributes (zone classification, risk tier), agent collection membership When governing the lifecycle of agent identities — provisioning, sponsor handoff, deprovisioning. This surface is owned by Control 2.25 at the governance-console level and by Control 2.26 (where present) at the directory level

9.2 Filter the Enterprise applications blade to agent identities

  1. Identity → Applications → Enterprise applications → All applications.
  2. Add a filter: Application type equals Agent (if the value does not appear in your filter dropdown, your tenant is not yet on the Agent ID preview ring; Policy C still applies to ordinary service principals).
  3. Optionally add Created on or after [date] to scope to recent agents.

9.3 Bind agent identities to Policy C

  1. Open Policy C (CA-003) from §7.
  2. Under Assignments → Users and workload identities → Workload identities → Include → Select service principals, add each agent identity from §9.2 that operates in Zone 3.
  3. Confirm each added SP has the Workload Identities Premium license (§7.1) — the field is on the SP's Properties page.
  4. Save the policy (it remains in Report-only; promotion is governed by §13).

9.4 Cross-reference to the Agent 365 Admin Center

Once an agent identity is in scope of Policy C, the Agent 365 Admin Center governance dashboard will display the CA enforcement state for that agent. Cross-reference Control 2.25 for the operational read-out — Agent Registry → [agent] → Identity & Access tab shows linked CA policies, last successful sign-in, and last blocked sign-in.

Agent ID preview is not a stable API contract

Schema, attribute names, blade locations, and supported CA conditions for Agent ID may change before GA. Document the portal version you verified against (header Last UI Verified date) and re-verify after each Microsoft Wave release. Avoid scripting against undocumented Agent ID endpoints during preview — use the portal-level Enterprise applications view, which is GA, as the durable enforcement plane.

10. Privileged Identity Management — activation-time MFA for AI / privileged roles

PIM converts standing privileged-role assignments into eligible assignments that the user must activate for a time-bound window. By requiring MFA on activation with the FSI Phishing-Resistant MFA strength, every privileged action is gated by AAL3-class authentication at the moment of use, not just at sign-in.

10.1 Configure PIM role settings

For each role in the table below, configure activation requires MFA with the phishing-resistant strength.

Role Maximum activation duration Requires MFA on activation Justification required Approval required Notification recipients
Entra Global Admin 2 hours Yes — FSI Phishing-Resistant MFA Yes (ticket #) Yes — 2 approvers from GA-Approvers group CISO, Compliance Officer
Power Platform Admin 4 hours Yes — FSI Phishing-Resistant MFA Yes Yes — 1 approver AI Administrator, Compliance Officer
Authentication Policy Admin 2 hours Yes — FSI Phishing-Resistant MFA Yes Yes — 1 approver CISO
Compliance Admin 4 hours Yes — FSI Phishing-Resistant MFA Yes No Purview Compliance Admin lead
AI Administrator 4 hours Yes — FSI Phishing-Resistant MFA Yes Yes — 1 approver AI Administrator lead, Compliance Officer

Note the canonical short name is AI Administrator (Microsoft built-in role added in 2025), not "AI Admin" or "AI Governance Administrator".

10.2 Per-role configuration steps

For each row in the table:

  1. https://entra.microsoft.com → Identity governance → Privileged Identity Management → Microsoft Entra roles → Roles.
  2. Click the role name (e.g., Entra Global Admin).
  3. Click Settings in the left rail.
  4. Click Edit.
  5. Activation tab:
  6. Activation maximum duration (hours): as per table.
  7. Check On activation, require multifactor authentication.
  8. Required authentication context: if available in your tenant, select FSI Phishing-Resistant MFA. If your tenant only exposes the boolean MFA-required toggle (older PIM UI), enable it and rely on Policy A to enforce the strength at the underlying sign-in.
  9. Check Require justification on activation.
  10. Check Require ticket information on activation.
  11. Assignment tab:
  12. Allow permanent eligible assignment: Yes (eligibility is long-lived).
  13. Allow permanent active assignment: No (force time-bound activation).
  14. Require multifactor authentication on active assignment: Yes.
  15. Notification tab: configure recipients per the table.
  16. Click Update.

10.3 Move standing assignments to eligible

For each role, review Assignments → Active assignments. Any user with a permanent active assignment should be converted to Eligible:

  1. Tick the user → Make eligible.
  2. Set the eligibility to Permanent eligible.
  3. The user must now activate via PIM each time they need the role.

Two-admin pattern for CA mutation

Conditional Access Admin should be configured with approval required (one approver from a separate group). This implements a two-admin / four-eyes pattern for any change to a CA policy — preventing an attacker who has compromised a single admin from creating an exclusion rule. Document this in the Control 2.5 — Privileged Access Lifecycle review cadence.

11. Sentinel Conditional Access Insights workbook

The Conditional Access Insights workbook visualizes policy impact, Report-only failures, and bypass patterns. Wire it to the Log Analytics workspace established in Control 3.9.

11.1 Confirm SigninLogs are flowing to Log Analytics

  1. https://entra.microsoft.com → Identity → Monitoring & health → Diagnostic settings.
  2. Confirm a diagnostic setting exists that ships SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, ManagedIdentitySignInLogs, and AuditLogs to the Log Analytics workspace defined in Control 3.9.
  3. If absent, click + Add diagnostic setting and configure all five log categories.

11.2 Open the Conditional Access Insights workbook

  1. https://security.microsoft.com → Microsoft Sentinel → Workbooks (if the Sentinel UI is not yet integrated into Defender in your tenant, navigate via https://portal.azure.com → Microsoft Sentinel → [workspace] → Workbooks).
  2. Click the Templates tab.
  3. Search for Conditional Access Insights and Reporting.
  4. Click Save to instantiate, choosing the Control 3.9 workspace.
  5. Click View saved workbook.

11.3 Pin daily / weekly cards to your governance dashboard

The workbook's most useful tiles for ongoing operations:

  • Sign-ins by Conditional Access Result — daily trend; investigate any spike in Failure immediately.
  • Top Conditional Access Failures by User — feeds the FINRA Notice 21-18 supervision narrative.
  • Workload Identity Sign-ins by Result — separate from human sign-ins; pin alongside Control 3.6's orphaned-agent dashboard.
  • Report-only Mode Impact — primary input to the §13 promotion decision.

11.4 Companion analytic rules

Sentinel ships several built-in analytic-rule templates that sit alongside this workbook. Enable at minimum:

  • Sign-in from unfamiliar location for Privileged Account.
  • Service Principal sign-in failure spike.
  • Conditional Access policy change (detects edits to CA policies — pair with the two-admin PIM pattern from §10.3).
  • Break-Glass account sign-in (see §12.4 for the bespoke rule).

The analytic-rule configuration steps live in Control 3.9.

12. Break-glass / emergency access accounts

Two cloud-only emergency accounts are required by the Microsoft baseline and by every FSI examiner-friendly architecture. They are the only safety net if a CA policy locks every named admin out of the tenant.

12.1 Create the two accounts

  1. https://entra.microsoft.com → Identity → Users → All users → + New user → Create new user.
  2. Account 1:
  3. User principal name: breakglass-01@<tenant>.onmicrosoft.com (use the .onmicrosoft.com domain, not a federated custom domain — the federation IdP is itself a single point of failure).
  4. Display name: Break-Glass Account 01 — DO NOT USE.
  5. Password: Auto-generated; record in two physically separated safes (see §12.3).
  6. Usage location: US (or your primary jurisdiction).
  7. After creation, assign Entra Global Admin as a permanent active assignment (PIM activation must not be on the critical path for emergency use).
  8. Repeat for breakglass-02@<tenant>.onmicrosoft.com.

12.2 Exclude break-glass accounts from every CA policy

  1. Create a security group Break-Glass-Accounts containing both accounts (Identity → Groups → All groups → + New group).
  2. For every CA policy you author (Policies A, B, C, D, plus any future ones), under Assignments → Users → Exclude → Users and groups, add the Break-Glass-Accounts group.
  3. The Microsoft Managed Policy Require multifactor authentication for admins likewise needs the exclusion — open it (filter by Source = Microsoft) and confirm the exclusion.

12.3 Physical storage and split knowledge

  • Account 1 password sealed in tamper-evident envelope, stored in CISO's office safe.
  • Account 2 password sealed in tamper-evident envelope, stored in a second physically separated safe (corporate secondary office or Iron Mountain vault).
  • Each FIDO2 hardware key (one per account) registered as the only authenticator and stored in the opposite safe from the password (so no single safe access yields a complete credential).
  • Quarterly verification (calendar reminder) that the envelopes are intact; tamper triggers a full break-glass credential rotation.

12.4 Sentinel analytic rule for any sign-in

A Sentinel analytic rule must alert on any sign-in (success or failure) by a break-glass account. The KQL is established in Control 3.9; summary form:

SigninLogs
| where UserPrincipalName in~ ("breakglass-01@<tenant>.onmicrosoft.com",
                                "breakglass-02@<tenant>.onmicrosoft.com")
| project TimeGenerated, UserPrincipalName, IPAddress, ResultType, AppDisplayName

The alert should page the CISO and at least one secondary on-call. A break-glass sign-in that is not pre-coordinated is a high-severity incident.

Break-glass is the only path back from a CA misconfiguration

Test the break-glass procedure at least quarterly. Sign in from a clean workstation, document the result, rotate the password, return it to the safe. An untested break-glass account is no break-glass account.

13. Report-only to Enforce rollout — the 7-day soak

Every policy authored in §§5–8 starts in Report-only. Promotion to On follows a documented soak period with explicit go/no-go criteria.

13.1 The 7-day window

Day Activity Owner
0 Policy created in Report-only; CAB ticket updated Conditional Access Admin
1 Verify Sign-in logs show the policy evaluating (Conditional Access tab populated) Entra Security Admin
2–6 Daily review of Report-only: Failure and Report-only: Success but interrupted results in the Sign-in logs and the §11 workbook Entra Security Admin
7 Go/no-go meeting with CISO, Compliance Officer, AI Administrator CISO chairs

13.2 Go criteria

Promote from Report-only to On only if:

  1. Report-only failure rate over the prior 24 hours is stable (not increasing day-over-day).
  2. Every Report-only failure has been triaged to one of three root causes:
  3. Legitimate user / SP needs to register a stronger authenticator or be added to a permitted IP — fix forward, not exclude.
  4. Service account that should be governed by Policy C, not Policy A/B — refactor scope.
  5. Stale / disabled identity that should not be signing in — investigate as potential incident.
  6. Break-glass accounts have been verified excluded (re-test by reading the policy JSON via https://entra.microsoft.com → Conditional Access → Policy → JSON view and grepping for the Break-Glass-Accounts group ID under excludeGroups).
  7. CAB has approved the cutover date and time.

13.3 No-go criteria — extend the soak

Extend by another 7 days (no shortcut) if any of:

  • Report-only failure rate is rising.
  • A Report-only failure cannot be attributed to a root cause.
  • A planned excluded SP is missing from the policy.
  • A new agent or maker has been onboarded mid-soak (their sign-ins need at least 48 h of observation).

13.4 The flip

  1. https://entra.microsoft.com → Protection → Conditional Access → Policies → [policy name].
  2. At the bottom, change Enable policy from Report-only to On.

  3. Click Save.

  4. Within 5 minutes, perform a smoke test:

  5. From a test account in scope, sign in to a covered cloud app and confirm the expected behavior (MFA challenge, block, or grant as appropriate).
  6. From a break-glass account on a clean workstation, sign in to confirm exclusion still functions (then sign out and rotate the credential).

  7. Inspect the §11 workbook for the new "Sign-ins by Conditional Access Result" tile and confirm Success and Failure populate as expected (not Report-only).

  8. Update the CAB ticket with go-live timestamp, evidence-pack screenshots, and the §15 evidence checklist.

14. Sovereign cloud parity — GCC, GCC High, DoD

Sovereign Cloud Availability — GCC / GCC High / DoD

Several capabilities used in this playbook have a lagging release schedule in US Gov sovereign clouds compared to commercial Microsoft 365. As of April 2026, the parity status is summarized below. Verify Microsoft Learn support tables before each enablement — sovereign feature ship dates change frequently.

Capability Commercial GCC GCC High DoD If unavailable, document as
Conditional Access (human users) GA GA GA GA —
Authentication Strengths (custom + built-in) GA GA GA GA —
Phishing-resistant MFA strength GA GA GA GA —
FIDO2, Windows Hello for Business GA GA GA GA —
Passkeys in Microsoft Authenticator GA Verify on Learn Verify on Learn Verify on Learn Product unavailability — see Microsoft Learn
Conditional Access for Workload Identities (CA-WID) GA Verify on Learn Verify on Learn Verify on Learn Product unavailability — substitute compensating controls (network segmentation, egress allow-list at firewall, certificate pinning)
Token Protection (Preview) Preview Not announced Not announced Not announced Product unavailability
Continuous Access Evaluation GA GA GA Verify on Learn —
Entra Agent ID (Preview) Public Preview (Frontier) Not announced Not announced Not announced Product unavailability — manage agent identities as ordinary service principals
Microsoft Sentinel CA Insights workbook GA GA GA GA —
Identity Protection (risky workload identities) GA Verify on Learn Verify on Learn Verify on Learn Compensating control: nightly KQL hunt for SP sign-in anomalies
Microsoft Agent 365 Admin Center GA (May 1, 2026) Not announced Not announced Not announced See Control 2.25 §1 sovereign variant

14.1 Documenting unavailability vs exception

When a capability is unavailable in your sovereign cloud, document it as product unavailability, not as a policy exception. The distinction matters to examiners:

  • Product unavailability is a fact about the platform; it is dated, references the Microsoft Learn page, and triggers the substitute compensating control (e.g., firewall egress allow-list in lieu of CA-WID). It is reviewed at each Microsoft Wave release.
  • Policy exception is an FSI-specific deviation from your firm's WSP that requires named approval, expiration date, and a quarterly review cycle.

Do not paper over a product unavailability as an exception — examiners reading your exception register expect to see firm-internal decisions, not Microsoft roadmap gaps.

14.2 Sovereign substitute pattern for CA-WID

If CA-WID is unavailable in your cloud, the substitute is layered:

  1. Network egress — restrict the source IPs from which agent service principals can authenticate, enforced at the firewall / NVA, not at the identity plane.
  2. Certificate-based authentication — bind agent SPs to certificates whose private keys are in an HSM or Azure Key Vault Premium; rotate every 90 days.
  3. Daily KQL hunt — run a Sentinel workbook tile that lists every SP sign-in from outside the permitted IP range and routes to incident response.
  4. Quarterly recheck — when CA-WID becomes available in your sovereign cloud, decommission the firewall workaround in favor of CA-WID and update this playbook.

15. Evidence pack and verification cross-references

Every promotion in §13 must produce evidence artifacts to the firm's compliance archive. The folder structure below mirrors the §13 cutover ticket.

15.1 Evidence pack folder structure

/compliance-archive/control-1.11/<YYYY-MM-DD-cutover>/
├── 00-cab-ticket.pdf
├── 01-pre-flight-license-validation.png             (§0.2)
├── 02-pim-eligible-assignments.csv                  (§0.1, exported via Get-AzureADMSPrivilegedRoleAssignment one-liner)
├── 03-auth-methods-policy-export.json               (§2 — exported from `https://entra.microsoft.com → Auth methods → ... → Export`)
├── 04-authentication-strength-FSI.json              (§3.2)
├── 05-named-locations.json                          (§4)
├── 06-policy-A-config.json                          (§5)
├── 07-policy-B-config.json                          (§6)
├── 08-policy-C-config.json                          (§7)
├── 09-policy-D-config.json                          (§8)
├── 10-pim-role-settings.csv                         (§10)
├── 11-sentinel-workbook-screenshot.png              (§11)
├── 12-breakglass-attestation-quarterly.pdf          (§12)
├── 13-reportonly-failure-triage-log.xlsx            (§13)
├── 14-sovereign-parity-attestation.pdf              (§14, if applicable)
└── 99-cisco-sign-off.pdf

15.2 Verification cross-references

The portal walkthrough produces the configuration evidence. The companion playbooks produce the operational evidence:

  • ./powershell-setup.md — same configuration via Microsoft Graph PowerShell SDK; preferred for repeatable rebuild and DR scenarios. Covers the Sync PIM eligibility to security group automation referenced in §2.6.
  • ./verification-testing.md — test cases VT-01 through VT-22 covering the Verification Criteria in the Control 1.11 spec. Run quarterly and after every CA policy change.
  • ./troubleshooting.md — issue catalog T-01 through T-25 keyed to the symptoms an admin sees in the Sign-in logs and CA Insights workbook.
  • ./conditional-access-agent-templates.md — copy-paste-ready JSON templates for Policies A, B, C, D and the FSI Authentication Strength.

15.3 Cross-control evidence joins

The 1.11 evidence pack does not stand alone. For an examiner-ready posture, join it to:

Joined control Evidence joined
Control 1.1 Maker-entitlement source-of-truth that populates Agent-Makers-All
Control 2.6 MRM register entry showing the agent identity and its MRM tier — drives whether Policy C applies
Control 2.12 Supervisory review of CA policy changes (FINRA Rule 3110 supervision of WSP changes)
Control 2.2 Environment classification (Z1/Z2/Z3) that drives Policy B and Policy C scoping
Control 2.25 Agent 365 dashboard view of per-agent CA enforcement state
Control 3.6 Orphaned-agent SP cleanup that maintains the cleanliness of Policy C's scope
Control 3.9 Log Analytics workspace + analytic rules + the KQL queries in §11 and §12

Anti-pattern catalog (top 10)

The patterns below have caused real outages in FSI tenants. Avoid them.

# Anti-pattern Why it fails Correct pattern
AP-01 Targeting "All cloud apps" with Require compliant device for all users Mobile device sign-ins to Outlook on personal phones are blocked tenant-wide Scope by group (Agent-Makers-All) and cloud app (Power Platform suite) — Policy B
AP-02 Disabling SMS / voice tenant-wide before users have registered alternatives Locks out users mid-migration Exclude Privileged-Role-Holders from SMS targets; leave SMS available as fallback for general users until passkey rollout completes — §2.6
AP-03 Skipping Report-only and going straight to On First incident is always tenant-wide Mandatory 7-day Report-only soak — §13
AP-04 Forgetting to exclude break-glass accounts First tenant lockout produces an "open Microsoft support ticket" stress event Always exclude Break-Glass-Accounts group on every policy — §12
AP-05 Applying CA-WID to a service principal without the Workload Identities Premium SKU Policy fails open silently; no enforcement Verify SKU before promotion — §0.2, §7.1
AP-06 Using "Block access" with no Require MFA fallback for human users Block is final; user has no path forward Use Grant access → Require authentication strength for humans; Block access is correct only for workload identities
AP-07 Combining Token Protection requirement with macOS / mobile users in scope Unsupported platform → blocked Scope Token Protection to Windows-only via Device Platform condition — §8.4
AP-08 Standing Entra Global Admin assignments Compromise → tenant takeover PIM eligible-only with phishing-resistant MFA on activation — §10
AP-09 Allowing any FIDO2 key (no AAGUID restriction) Consumer-grade key with weak attestation accepted AAGUID allow-list — §2.2
AP-10 Documenting sovereign-cloud capability gaps as "policy exceptions" instead of "product unavailability" Examiner reads exception register as firm-internal deviation Document as product unavailability with Microsoft Learn link — §14.1

Summary

You have configured the four foundational Conditional Access policies for AI agents in an FSI Microsoft 365 tenant: Policy A for privileged-role phishing-resistant MFA, Policy B for agent-maker compliant-device + phishing-resistant MFA, Policy C for workload-identity location and risk fencing, and Policy D (plus pilot Policy E / CA-005) for session-layer controls including CAE, sign-in frequency, and Token Protection. You have promoted them through a 7-day Report-only soak, wired the Sentinel CA Insights workbook to the Control 3.9 workspace, and confirmed the break-glass posture. You have documented sovereign-cloud unavailability where applicable and refreshed the evidence pack for examiner review.

These configurations support compliance with NYDFS §500.12, FFIEC authentication guidance, SEC Reg S-P, FINRA Notice 21-18, NIST SP 800-63B AAL3, and CISA Zero Trust identity-pillar expectations. They do not by themselves satisfy any obligation; the joined controls in §15.3 carry the rest of the load.

Continue with ./verification-testing.md to run the Verification Criteria checklist, ./powershell-setup.md to produce the same configuration via code for DR rebuild, and ./troubleshooting.md when sign-in failures need triage.

Updated: April 2026 | Version: v1.4.0 | UI Verification Status: Current