# Control 1.11: Conditional Access and Phishing-Resistant MFA

**Control ID:** 1.11<br>
**Pillar:** Security<br>
**Regulatory Reference:** GLBA 501(b) and FTC Safeguards Rule 16 CFR §314.4(c)(5) (MFA mandate, in force June 2023), SEC Regulation S-P (May 2024 amendments — incident response & customer notification), FINRA 4511, FINRA 3110, FINRA Regulatory Notice 21-18 (cybersecurity), FINRA RN 24-09, SEC 17a-3/4, SOX 302, NYDFS 23 NYCRR 500 §500.12 (Second Amendment; universal MFA fully effective Nov 1, 2025), NIST SP 800-63B AAL3, FFIEC Authentication and Access to Financial Institution Services and Systems (Aug 2021), CISA Zero Trust Maturity Model v2.0 (Identity pillar), OCC Bulletin 2026-13 (formerly OCC Bulletin 2011-12) / Federal Reserve SR 26-2 (formerly SR 11-7) (Model Risk Management — authentication controls on model-serving endpoints)<br>
**Last UI Verified:** April 2026<br>
**Governance Levels:** Baseline / Recommended / Regulated<br>

---

!!! tip "Agent 365 Architecture Update"
    Entra Agent ID extends Conditional Access to agent identities with agent-specific risk signals and custom security attributes. Agents can now be represented as first-class identities subject to risk-based policies, **complementing — and potentially over time reducing dependence on — per-platform identity models** such as service principals and managed identities. Microsoft Entra Agent ID itself reached general availability in **April 2026** ([Entra Agent ID — What's new](https://learn.microsoft.com/en-us/entra/agent-id/whats-new-agent-id)); the **Microsoft Agent 365** control plane that bundles Agent ID licensing into the Agent 365 / **Microsoft 365 E7** ("Frontier Suite") SKUs became generally available on **May 1, 2026** ([Agent 365 admin overview](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-365-overview)). See [Unified Agent Governance](../../framework/agent-identity-architecture.md) for agent Conditional Access policy examples and configuration guidance.

    **Agent Registry Visibility (Updated May 2026):** Microsoft Copilot Studio agents and Microsoft Copilot agents (e.g., declarative agents) are covered by the unified **Microsoft Agent 365 registry** per the [Agent Registry convergence](https://learn.microsoft.com/en-us/entra/agent-id/agent-registry-convergence) documentation — Agent 365 is the unified registry and control plane, while Microsoft Entra continues to provide the identity foundation through Agent ID. Declarative agents appear in the registry but lack org-wide deployment capability — export/import is required for broader distribution, and direct publish is under consideration. Admins can block or delete declarative agents but cannot deploy them org-wide from the registry.

    **Coverage note — Azure AI Foundry agents:** Microsoft documentation explicitly states that Azure AI Foundry agents are **not currently included** in the unified Microsoft Agent 365 registry (and do not have Microsoft Entra Agent ID identities surfaced there). Foundry Agent Applications are documented separately at the [Azure AI Foundry agent applications](https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/agent-applications) page. Until Microsoft confirms convergence, organizations using Foundry agents must apply Control 1.11 compensating controls (separate registration, separate audit, parallel identity governance) — they cannot rely on the Agent 365 / Entra Agent ID registry to enumerate or attest Foundry agents.

!!! note "Frontier program and Agent 365 coexistence"
    Microsoft's Frontier program (Microsoft 365 E7: The Frontier Suite, US$99/user/month) remains active after the general availability of Microsoft Agent 365. Frontier provides early access to scenarios like Project Opal that are gated behind the Frontier subscription, while Agent 365 covers the core agent governance and administration surface. The two coexist; this control's guidance applies under both programs. See the [Frontier Suite get-started guide](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/get-started-frontier) and the [Agent 365 admin overview](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-365-overview) for current scope.

## Objective

Implement adaptive access control using Microsoft Entra Conditional Access to enforce risk-based policies for users creating and managing AI agents, and for agents themselves through Microsoft Entra Agent ID and Conditional Access for Workload Identities. This control helps restrict agent creation, publication, and management to authorized, authenticated principals (human users and agent identities) and supports near-real-time response via Continuous Access Evaluation when risk events occur.

!!! warning "Scope Limit — What Conditional Access Does and Does Not Do"
    Conditional Access governs **identity context** — who (or what workload identity) can authenticate, from where, under what device / risk posture, and with what session lifetime. **Phishing-resistant MFA in this control applies to human makers, owners, sponsors, and administrators** of AI agents. It does **not** apply to agent identities themselves, which have no user to challenge; agent identities are governed through Conditional Access for Workload Identities (CA WID) and Entra Agent ID (GA April 2026; Agent 365 / M365 E7 licensing bundle GA May 1, 2026) where available.

    CA does **not**:

    - Inspect, validate, or constrain an agent's prompts, tool calls, plans, or generated output (see [Control 1.21 Adversarial Input Logging](1.21-adversarial-input-logging.md) and DLP-for-Copilot in [Control 1.5](1.5-data-loss-prevention-dlp-and-sensitivity-labels.md)).
    - Authenticate or attest the agent's reasoning, retrieved grounding data, or model provenance (see [Control 2.5 Testing, Validation and Quality Assurance](../pillar-2-management/2.5-testing-validation-and-quality-assurance.md) and model-risk controls under OCC Bulletin 2026-13 (formerly OCC 2011-12) / Fed SR 26-2 (formerly SR 11-7) in [Control 2.6](../pillar-2-management/2.6-model-risk-management-sr-26-2.md)).
    - Replace per-connector action governance (see [Control 1.4](1.4-advanced-connector-policies-acp.md)), content-level protection (see [Control 1.5](1.5-data-loss-prevention-dlp-and-sensitivity-labels.md)), or supervisory review (see [Control 2.12](../pillar-2-management/2.12-supervision-and-oversight-finra-rule-3110.md)).

    Agent-scoped CA + Identity Protection signals are **behavioral signals on the identity plane**, not reasoning-level validation. Treat this control as one layer in defense-in-depth, not a substitute for runtime content controls or MRM validation.

---

## Why This Matters for FSI

- **GLBA / FTC Safeguards Rule 16 CFR §314.4(c)(5):** Helps meet the explicit MFA mandate (in force June 2023) for any individual accessing customer information. Applies to non-bank FSIs (broker-dealers, RIAs, insurers, fintechs) under FTC enforcement; bank-supervised FSIs receive equivalent guidance via FFIEC and OCC. The MFA requirement lives in the FTC Safeguards Rule, not in GLBA §501(b) directly — cite both.
- **SEC Regulation S-P (May 2024 amendments):** Strengthened safeguards rule, incident-response program, and 30-day customer-notification clock. MFA failures and CA bypasses are an in-scope incident trigger.
- **FINRA Rule 4511 / RN 24-09 / Notice 21-18:** Access control and audit trails for records; FINRA Regulatory Notice 21-18 reinforces that member firms should consider MFA, access management, and continuous monitoring as part of reasonable cybersecurity controls; FINRA Regulatory Notice 24-09 (Generative AI / LLM Guidance) applies existing supervisory and recordkeeping rules to AI tools on a technology-neutral basis, which includes the identity-and-access controls that gate access to AI agents. FINRA retired SMS/voice MFA for Gateway access (July 2025), signaling direction on acceptable MFA methods for member firms.
- **SEC 17a-3/4:** Access controls supporting recordkeeping integrity; sign-in logs are evidence under 17a-4(b)(4).
- **SOX 302 / 404:** Internal access controls for systems supporting financial reporting; PIM activation logs and break-glass test records are common SOX evidence requests.
- **NYDFS 23 NYCRR 500 §500.12 (Second Amendment, Nov 2023):** Universal MFA for **all individuals** accessing **any** information system, fully effective **Nov 1, 2025**. CISO-approved exceptions only, with annual review and compensating controls.
- **OCC Bulletin 2026-13 (formerly OCC 2011-12) / Fed SR 26-2 (formerly SR 11-7) (Model Risk Management):** AI agents and Copilot Studio bots that inform or automate decisions are in-scope "models." Authentication and access controls on model-serving endpoints (maker portals, agent runtimes, Entra Agent ID principals) are a core MRM effectiveness control — weak identity controls on the model-serving path undermine the validation and ongoing-monitoring requirements. CA policies targeting maker / admin / agent identities help support the "controls around model use" expectations in Fed SR 26-2 (formerly SR 11-7) §V, but do not by themselves satisfy MRM obligations (see [Control 2.6](../pillar-2-management/2.6-model-risk-management-sr-26-2.md)).
- **NIST SP 800-63B:** Phishing-resistant authenticators required at AAL3; hardware-bound or device-bound credential required; OTP not permitted at AAL3. Synced (cross-device) passkeys do not meet AAL3 — require device-bound.
- **FFIEC Authentication and Access to Financial Institution Services and Systems (Aug 2021, ref. SR 21-14):** Risk-based MFA required for customers, employees, vendors, service accounts, and API access; layered security expected for high-risk transactions.
- **CISA Zero Trust Maturity Model v2.0 (Identity pillar):** Phishing-resistant MFA, continuous validation (CAE), and risk-adaptive policies are the "Advanced" / "Optimal" target state.

---

!!! tip "Automation Available"
    Companion solutions in [FSI-AgentGov-Solutions](https://github.com/judeper/FSI-AgentGov-Solutions):

    - [Conditional Access Automation](https://github.com/judeper/FSI-AgentGov-Solutions/tree/main/conditional-access-automation) — CA policy deployment, compliance monitoring, and drift detection for AI workloads
    - [Session Security Configurator](https://github.com/judeper/FSI-AgentGov-Solutions/tree/main/session-security-configurator) — automated session security validation per governance zone with drift detection


## Control Description

| Capability | Description |
|------------|-------------|
| Conditional Access policies | Risk-based access control for agent creators |
| Phishing-resistant MFA | FIDO2 security keys; **device-bound passkeys** in Microsoft Authenticator (synced/cross-device passkeys do **not** meet AAL3); **Windows Hello for Business** (cloud Kerberos trust recommended; cert trust supported; **key trust on deprecation path**); **certificate-based authentication (CBA)** including PIV/CAC for federal-adjacent tenants; Platform SSO on macOS. Configure via **Authentication Strengths** policy. |
| Agent identity protection | Entra Agent ID for AI agent governance |
| Authentication strengths | Tiered authentication requirements |
| Agent sponsorship | Human accountability for agent lifecycle |

---

## Key Configuration Points

- Configure Conditional Access policies requiring MFA for all users
- Define authentication strengths (phishing-resistant for enterprise zone)
- Exclude and validate break-glass (emergency access) accounts
- Configure named locations for trusted networks
- Enable Microsoft Entra Agent ID for agent identity governance
- Assign human sponsors to Zone 2/3 agents
- Use Quarantined collection for agents pending compliance review
- Configure Privileged Identity Management (PIM) for AI administration roles

!!! warning "Service Principal Security Group Bypass"
    Service Principals used by Power Automate flows and automation scripts may not be members of security groups used in Conditional Access policy assignments, causing them to bypass CA controls. This occurs because Service Principals are application identities without user group membership.

    **Compensating Controls:**

    - Use **Named Locations** to restrict Service Principal sign-ins to trusted IP ranges
    - Apply **app-specific CA policies** targeting Service Principal application IDs directly
    - Monitor Service Principal sign-ins via Entra ID Sign-in Logs with filter `User Type = Service Principal`
    - Review Service Principal consent and permissions quarterly per Control 2.8

    See [Conditional Access Automation](https://github.com/judeper/FSI-AgentGov-Solutions/tree/main/conditional-access-automation) solution for Service Principal CA policy templates.

!!! info "License Requirements"
    | Capability | Required SKU | Notes |
    |---|---|---|
    | Conditional Access for users | Microsoft Entra ID P1 | Included in M365 E3/E5, Business Premium |
    | Identity Protection (risky users / sign-ins) | Microsoft Entra ID P2 | Required for `User risk = High` token-theft policy |
    | Privileged Identity Management (PIM) | Microsoft Entra ID P2 | Required for JIT directory role activation |
    | Access Reviews / ID Governance access packages | Microsoft Entra ID P2 (or Entra ID Governance add-on) | Agent Sponsor access package, break-glass quarterly review |
    | **Conditional Access for Workload Identities (CA WID)** | **Workload Identities Premium add-on** | **Per service-principal / managed-identity / agent-identity per month — Entra ID P1/P2 alone is not sufficient.** |
    | **Identity Protection for workload identities** | Workload Identities Premium add-on | Risk feed into CA WID policies |
    | **Microsoft Entra Agent ID** | Entra Agent ID platform GA April 2026; Microsoft Agent 365 or Microsoft 365 E7 licensing bundle GA May 1, 2026 | Rides on top of CA WID — Workload Identities Premium is a prerequisite |
    | Microsoft Authenticator (device-bound passkey) | Free (recent app version required) | Device-bound required for AAL3; synced passkeys do not satisfy AAL3 |
    | FIDO2 security keys | Per-user hardware cost (vendor-dependent) | FIPS 140-2 / 140-3 keys required for federal-adjacent tenants |
    | Microsoft Sentinel CA Insights workbook | Microsoft Sentinel + Entra ID sign-in log ingestion | Required for `Report-only → On` promotion analysis |
    | Defender for Identity (hybrid sign-in correlation) | Microsoft Defender for Identity (M365 E5 Security or standalone) | Limited coverage for cloud-only agent / managed identities |

!!! info "Sovereign Cloud Considerations"
    | Capability | Commercial | GCC | GCC High | DoD |
    |---|---|---|---|---|
    | Conditional Access (users) | GA | GA | GA | GA |
    | CA for Workload Identities | GA | GA | Verify GA date with FastTrack | Verify GA date with FastTrack |
    | Workload Identities Premium SKU | Available | Available | Verify availability | Verify availability |
    | Microsoft Entra Agent ID | Platform GA April 2026; Microsoft Agent 365 / M365 E7 ("Frontier Suite") licensing bundle GA May 1, 2026 | Verify Agent 365 / E7 SKU availability with FastTrack | Not yet announced | Not yet announced |
    | Identity Protection (workload identities) | GA | GA | Verify with FastTrack | Verify with FastTrack |
    | PIM | GA | GA | GA | GA |
    | FIDO2 / device-bound passkey | GA | GA | GA (FIPS 140-2/3 keys required) | GA (FIPS 140-2/3 keys required) |
    | Certificate-based authentication (PIV/CAC) | GA | GA | GA | GA |
    | Continuous Access Evaluation | GA | GA | GA | GA |
    | Token Protection | Public Preview | Public Preview | Verify availability | Verify availability |
    | Microsoft Authenticator (device-bound passkey) | GA | GA | GA — must be FedRAMP-High deployment | GA — must be FedRAMP-High deployment |
    | Microsoft Sentinel CA Insights workbook | GA | GA | GA | GA |

    Document any gap as a compensating control (e.g., agent identities in GCC High governed via SP-targeted CA WID + Workload Identities Premium until Entra Agent ID lands).

### PIM Baselines for AI Administration Roles

Privileged Identity Management (PIM) provides just-in-time access for AI governance roles. Configure PIM for:

| Role | PIM Setting | Activation Duration | Approval Required |
|------|-------------|---------------------|-------------------|
| **Power Platform Admin** | Eligible | 4 hours max | Yes - AI Governance Lead |
| **Entra Security Admin** | Eligible | 4 hours max | Yes - Security Manager |
| **Purview Compliance Admin** | Eligible | 8 hours max | Yes - Compliance Officer |
| **Environment Admin** | Eligible | 4 hours max | Yes - AI Governance Lead |
| **Agent Sponsor (Zone 3)** — implemented via Entra ID Governance access package, **not** a built-in directory role | Time-bound assignment via access package | 8 hours max | Yes — Compliance Officer |

> *Agent Sponsor* is a governance role, not an Entra built-in directory role. Implement via an Entra ID Governance access package (Entra ID P2) bound to a security group used for agent ownership tagging in [Control 2.26](../pillar-2-management/2.26-entra-agent-id-identity-governance.md). PIM-style JIT semantics are achieved through access-package time-bound assignment, not through PIM for directory roles.

**PIM Configuration for AI Governance:**

1. Enable PIM for all AI administration directory roles
2. Require MFA at activation (phishing-resistant for Zone 3)
3. Configure justification requirement with audit logging
4. Set maximum activation duration per role sensitivity
5. Configure approval workflows with backup approvers
6. Enable alerts for PIM activation failures and anomalies

### Continuous Access Evaluation, Token Protection, and Session Controls

**Continuous Access Evaluation (CAE)** is GA and is the near-real-time revocation lever for sessions. CAE allows Entra ID and supporting resource providers (Exchange, SharePoint, Graph, Teams) to revoke sessions in minutes (rather than waiting for token expiry) on critical events: account disable, password change, MFA registration change, high user risk, admin-revoke. Required for Zone 2 and Zone 3.

- Confirm CAE is enabled (default On for new tenants; verify under **Conditional Access > Session > Customize continuous access evaluation** for legacy tenants).
- Confirm Copilot, Copilot Studio, and Microsoft Graph clients show `Continuous access evaluation = True` in Sign-in Logs.

**Token Protection (TP)** binds the sign-in token to the originating device, defeating most token-theft / AitM replay attacks. In public preview as of early 2026 with expanding workload coverage. Pilot on Zone 3 maker / admin populations under **Report-only** first; track coverage gaps (non-Windows clients, certain mobile apps) because TP enforce mode will block uncovered clients.

**Sign-in Frequency for Copilot / Copilot Studio sessions.** Configure CA Session controls:

- Zone 3 maker / admin portals (Power Platform admin center, Copilot Studio author): **Sign-in frequency ≤ 4 hours**, **Persistent browser session = Never persistent**.
- Zone 2: **Sign-in frequency ≤ 12 hours**.
- Zone 1: tenant default acceptable.

**Token theft detection** is a user-risk signal in Entra ID Protection. Configure a CA policy on `User risk = High` to require password change + reauthentication (or block) for users with this signal. Required for Zone 3.

### Conditional Access for Workload Identities (GA — paid SKU required)

Conditional Access for Workload Identities (CA WID) is **GA** and is the supported mechanism for applying CA policies to service principals, managed identities, and (via Entra Agent ID) agent identities. CA WID is the fix for the Service Principal bypass described above — it does **not** rely on user-group membership.

!!! warning "License: Workload Identities Premium add-on required"
    CA WID requires the **Workload Identities Premium** add-on SKU, billed per workload identity per month. Entra ID P1 / P2 alone is **not** sufficient — without this SKU you can author the policy but enforcement will not apply. Confirm SKU coverage of every service principal, managed identity, and agent identity in scope **before** relying on CA WID as a primary control.

**Coverage notes:**

- CA WID supports **Locations** and **Block** controls for workload identities.
- User-targeted Grant controls (MFA, compliant device, terms of use) do not apply — workload identities have no user to challenge.
- For agents authenticating as managed identities, CA WID + Workload Identities Premium is required to bring them under the same policy plane as human users.
- Pair with **Identity Protection for workload identities** (also licensed under Workload Identities Premium) to feed risk into CA policy evaluation.

### Entra Agent ID: Conditional Access and Identity Protection for Agents

!!! info "Generally Available — April 2026 (Agent 365 licensing bundle GA May 1, 2026)"
    Microsoft Entra Agent ID reached general availability in **April 2026** ([Entra Agent ID — What's new](https://learn.microsoft.com/en-us/entra/agent-id/whats-new-agent-id)); the **Microsoft Agent 365** / **Microsoft 365 E7** licensing bundle that packages Agent ID into the Agent 365 control plane became generally available on **May 1, 2026** ([Agent 365 admin overview](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-365-overview)). Entra Agent ID rides on top of **CA for Workload Identities** (above) — the Workload Identities Premium SKU is a prerequisite. Some related surfaces (e.g., the `agentSignIn` resource type in Entra logs) remain in Public Preview; verify current preview/GA status against Microsoft Learn before relying on specific behaviors in production.

Entra Agent ID assigns each AI agent a first-class identity in Microsoft Entra, enabling agent-specific Conditional Access and Identity Protection policies that operate independently of the human-user Conditional Access policies already documented in this control. Both sets of policies are required in a mature FSI governance posture because they protect different principals and address different threat surfaces.

!!! note "Key distinction from existing CA policies in this control"
    The CA policies described elsewhere in this control target **human principals** such as makers, admins, and agent creators. The policies described in this section target **agent identities themselves** as authenticated principals. Both layers are necessary and complementary.

#### Conditional Access for Agents

Agent-specific CA policies extend the standard Entra CA framework to workload identities representing AI agents. Capabilities expanded alongside Entra Agent ID GA (April 2026); some specific CA-for-agents surfaces may remain in Public Preview — verify current status against Microsoft Learn before relying on a specific surface in production policy. The capabilities below are documented on Microsoft Learn for Entra Agent ID and require **Microsoft Agent 365 or Microsoft 365 E7** licensing (Agent 365 bundle GA May 1, 2026) alongside the Workload Identities Premium SKU prerequisite for CA WID:

| Capability | Description |
|---|---|
| Agent-scoped CA policies | Create CA policies that apply to agent identities rather than human users |
| Agent resource targeting | Scope policies to specific agent-accessed resources within the CA policy target |
| Agent risk signal triggers | Trigger policy conditions based on agent-level risk signals rather than user risk |
| Microsoft Managed Policies | Microsoft-provided baseline policies that automatically block agents flagged as high risk |
| Custom security attribute scoping | Apply one policy to all agents sharing a custom attribute such as `AgentZone = 3` |
| Per-agent fine-grained control | Individual agent-level policy assignments remain supported alongside scale policies |

**Microsoft Managed Policies** provide a Microsoft-maintained baseline layer of protection. When enabled, these policies automatically block agent access for any agent identity assessed as high risk by the Entra platform without requiring custom policy authoring. This is the recommended minimum baseline for Zone 2 and Zone 3 agents in FSI environments.

**Custom security attribute-based scale deployment** is the recommended approach for governing large agent populations. For example, tagging all Zone 3 agents with `AgentZone = 3` and creating a single CA policy scoped to that attribute eliminates the need to maintain per-agent policy assignments. Individual overrides remain available where warranted.

**Portal Path - Configure CA Policies for Agents:**

```text
Microsoft Entra admin center
  > Protection
    > Conditional Access
      > Policies
        > + New policy
          > Users and workload identities
            > Select: Service principals / Agent identities
```

**Zone 3 Agent - Recommended CA Policy Configuration:**

1. Navigate to the portal path above and create a new CA policy.
2. Under **Users and workload identities**, select **Service principals** or **Agent identities** depending on portal version.
3. Under **Conditions**, scope to agents carrying the custom attribute `AgentZone = 3`.
4. Under **Grant**, configure a block when agent risk is unacceptable, or require compliance with a named location policy.
5. Enable the policy in **Report-only** mode first and promote it to **On** after validation.

**Verify Microsoft-managed Conditional Access policies:**

```text
Microsoft Entra admin center
  > Protection
    > Conditional Access
      > Policies
        > Filter: Source = Microsoft
```

Microsoft-managed CA policies appear inline in the policy list with a "Microsoft-managed" badge — there is no separate top-level menu. Confirm that the Microsoft-managed baseline that blocks high-risk agent / workload identities is listed and shows `On` (not `Report-only` and not `Off`). The exact display name may change before GA — filter by `Source = Microsoft` rather than searching by name. Microsoft-managed policies cannot be edited directly; duplicate them for tenant-specific tuning, and document any per-policy opt-out with justification.

#### Identity Protection for Agents (Preview)

Microsoft Entra ID Protection has been extended to detect and respond to threats from AI agent identities. The following detections and controls are available:

| Signal / Control | Description |
|---|---|
| Anomalous resource access | Agent accessing resources it has never previously accessed |
| Excessive sign-in attempts | Unusual frequency of authentication events from an agent identity |
| Suspicious access patterns | Access patterns inconsistent with the agent's declared function or expected baseline |
| Risk feed into CA policies | Elevated agent risk score feeds directly into CA policy evaluation |
| Microsoft Managed Policy blocking | Compromised agents can be blocked via the managed baseline policy |
| Risk reports | Agent risk events appear in Entra ID Protection risky workload identity reports |

**Monitor Agent Risk Events:**

```text
Microsoft Entra admin center
  > Security
    > Identity Protection
      > Risky workload identities
```

Review this view as part of the weekly governance cycle for Zone 2 and Zone 3 agents. Investigate any agent with a risk level of **High** or **Medium** before dismissing the risk event.

!!! warning "Do not dismiss agent risk events without investigation"
    Dismissing a risky workload identity event without documented investigation creates a governance gap. Each dismissed event should have a corresponding ticket or documented review in your ITSM system.

#### Summary: CA and Identity Protection Configuration Checklist

| Task | Required Zone | Status Field |
|---|---|---|
| Microsoft Agent 365 or Microsoft 365 E7 licensing provisioned (Entra Agent ID platform GA April 2026; Agent 365 bundle GA May 1, 2026) | Zone 2, Zone 3 | [ ] |
| Microsoft Managed Policies enabled (block high-risk agents baseline) | Zone 2, Zone 3 | [ ] |
| Agent-specific CA policies created and kept distinct from user CA policies | Zone 2, Zone 3 | [ ] |
| Custom security attributes applied to agents for CA scoping | Zone 3 | [ ] |
| CA policy scoped to `AgentZone = 3` attribute deployed | Zone 3 | [ ] |
| Identity Protection risky workload identities review scheduled weekly | Zone 2, Zone 3 | [ ] |
| Agent risk event dismissal procedure documented in ITSM | Zone 2, Zone 3 | [ ] |

---

## Agent Identity Governance: Agent ID vs. Blueprint

Microsoft provides two complementary approaches for agent identity governance. Understanding when to use each is essential for Zone 2+ deployments. This subsection is informational and sits alongside the Key Configuration Points above; for the full decision record see [Agent Identity Architecture](../../framework/agent-identity-architecture.md).

### When to Use Agent ID Only

- Zone 1 agents with simple identity requirements
- Single-tenant deployments with limited scale
- Direct identity assignment via Entra

### When to Use Blueprint (Recommended for Zone 2+)

- Enterprise-scale deployments with multiple agents
- Multi-tenant agent platforms
- Formal governance registry required
- Regulatory audit trail requirements

### Decision Matrix

| Requirement | Agent ID Only | Agent ID + Blueprint |
|-------------|---------------|----------------------|
| Single agent | Sufficient | Optional |
| Multi-tenant | Not supported | Required |
| Regulatory audit | Partial | Full |
| Zone 1 | Sufficient | Optional |
| Zone 2 | Possible | Recommended |
| Zone 3 | Not recommended | Required |

For comprehensive guidance, see [Agent Identity Architecture](../../framework/agent-identity-architecture.md).

### Unified Control Plane Visibility with Agent 365

Control 1.11 focuses on Conditional Access policy configuration for users creating agents (maker identity) and for agents themselves (Entra Agent ID). [Agent 365 Architecture](../../framework/agent-identity-architecture.md) provides the unified control plane that surfaces how these Conditional Access policies apply across all agent types — Copilot Studio, Agent Builder, SharePoint Agents, and third-party agents.

While this control documents **policy configuration**, Agent 365 provides **cross-platform visibility** into policy enforcement and compliance status for all agents in your organization. This visibility is especially valuable in Zone 3 deployments where multiple agent platforms require consistent Conditional Access governance. See [Control 2.25](../pillar-2-management/2.25-agent-365-admin-center-governance-console.md) for the operational surface.

---

## Zone-Specific Requirements

| Zone | Requirement | Rationale |
|------|-------------|-----------|
| **Zone 1** (Personal) | Baseline MFA for human users; document exceptions | Reduce risk while keeping friction low |
| **Zone 2** (Team) | Strong auth for human admin / maker roles; CA WID / Entra Agent ID policies applied to supported agent workload identities; identified owner | Shared agents increase blast radius |
| **Zone 3** (Enterprise) | **Phishing-resistant MFA enforced for human makers / owners / admins** (not for the agents themselves); CA WID / Entra Agent ID controls applied to agent identities where available; compensating controls documented for preview, sovereign-cloud, or unsupported-client gaps | Highest audit / regulatory risk and strongest identity-assurance expectation |

---

## Roles & Responsibilities

| Role | Responsibility |
|------|----------------|
| **Entra Security Admin** | Conditional Access policy authoring, Authentication Strengths configuration, Identity Protection configuration |
| **Authentication Policy Admin** | Tenant Authentication Methods policy (which authenticators are enabled and for whom); FIDO2 / passkey / CBA tenant configuration |
| **Authentication Administrator** | Per-user authentication method management (registration / reset) for non-admin users |
| **Entra Privileged Role Admin** | PIM configuration for AI / Power Platform / Purview directory roles; PIM approval policy and break-glass exclusion |
| **Entra Identity Governance Admin** | Access reviews on agent identities, break-glass account quarterly review, Agent Sponsor access-package configuration |
| **Entra Agent ID Admin** | Agent identity registration and lifecycle (GA April 2026); pairs with Control 2.26 |
| **AI Administrator** | M365 Copilot / Copilot Studio feature access controls that ride on top of CA scoping |
| **Power Platform Admin** | Power Platform / Copilot Studio environment scoping that anchors CA app-targeting |
| **SOC Analyst (Sentinel / Defender XDR)** | Triage break-glass sign-in alerts, Token theft detection events, risky workload-identity events; operate the Sentinel CA Insights workbook |
| **CISO** | Approve Zone 3 phishing-resistant enforcement posture, break-glass procedure, NYDFS §500.12 exceptions |
| **Compliance Officer** | Regulatory mapping (GLBA / FTC Safeguards Rule, FINRA Rule 4511 / RN 24-09, SEC Reg S-P, NYDFS §500.12); supervisory sign-off |
| **Designated Supervisor / Registered Principal** | FINRA Rule 3110 supervisory sign-off for broker-dealer recordkeeping-scope agents |
| **AI Governance Lead** | Cross-plane policy ownership (zone-to-CA-policy mapping, Agent Sponsor model); convene quarterly access reviews |
| **Agent Owner / Sponsor** (governance role, not directory role) | Accountability anchor for the agent identities targeted by agent-scoped CA policies |

---

## Related Controls

| Control | Relationship |
|---------|--------------|
| [1.4 - Advanced Connector Policies](1.4-advanced-connector-policies-acp.md) | Connector access control complements CA scoping for Power Platform actions |
| [1.5 - DLP and Sensitivity Labels](1.5-data-loss-prevention-dlp-and-sensitivity-labels.md) | DLP-for-Copilot enforcement assumes the user is authenticated under the right CA posture |
| [1.7 - Audit Logging](1.7-comprehensive-audit-logging-and-compliance.md) | Sign-in logs and CA evaluation events are the join key for `CopilotInteraction` and incident investigation |
| [1.12 - Insider Risk Detection](1.12-insider-risk-detection-and-response.md) | Risky-user signal feeds CA `User risk = High` policy; Token theft detection is a Zone 3 trigger |
| [1.19 - eDiscovery for Agent Interactions](1.19-ediscovery-for-agent-interactions.md) | Sign-in logs are evidence preserved under hold for FINRA 8210 / SEC 17a-4(b)(4) production |
| [1.21 - Adversarial Input Logging](1.21-adversarial-input-logging.md) | Defender XDR Copilot incidents trigger CA response actions on the user; the CA → IdP plane is the response lever |
| [2.5 - Testing, Validation and Quality Assurance](../pillar-2-management/2.5-testing-validation-and-quality-assurance.md) | Validates CA policy effectiveness via What-If, sampling gates, and report-only soak before promotion |
| [2.8 - Access Control and Segregation of Duties](../pillar-2-management/2.8-access-control-and-segregation-of-duties.md) | Service Principal CA bypass mitigation (CA WID) depends on access-control inventory; two-admin / SoD pattern for CA authoring + approval |
| [2.22 - Inactivity Timeout Enforcement](../pillar-2-management/2.22-inactivity-timeout-enforcement.md) | 1.11 governs CA session frequency; 2.22 governs application-level inactivity at the PPAC layer |
| [2.26 - Entra Agent ID Identity Governance](../pillar-2-management/2.26-entra-agent-id-identity-governance.md) | Lifecycle companion to agent CA: agent provisioning, sponsorship, and deprovisioning that underpins CA policy targeting |
| [3.1 - Agent Inventory](../pillar-3-reporting/3.1-agent-inventory-and-metadata-management.md) | Inventory is the source of `AgentZone` custom security attribute used by attribute-scoped agent CA policies |
| [2.25 - Microsoft Agent 365 — Admin Center Governance Console](../pillar-2-management/2.25-agent-365-admin-center-governance-console.md) | Provides unified visibility into how the CA posture described here applies across agent types and platforms |
| [3.6 - Orphaned Agent Detection and Remediation](../pillar-3-reporting/3.6-orphaned-agent-detection-and-remediation.md) | Orphaned agents break the sponsor/owner accountability model that this control assumes for Zone 2 and Zone 3 governance |
| [3.8 - Copilot Hub](../pillar-3-reporting/3.8-copilot-hub-and-governance-dashboard.md) | Cross-platform visibility into CA enforcement posture for all agent types |

---

!!! tip "Automated Compliance: Conditional Access Automation"
    For automated CA policy deployment, daily compliance scanning, and drift detection for AI workloads, see the **Conditional Access Automation** solution.

    **Capabilities:**

    - 8 zone-specific CA policy templates for Copilot Studio, Agent Builder, M365 Copilot
    - Daily compliance scanning with break-glass exclusion verification
    - Multi-dimensional drift detection (policy disabled, conditions weakened, controls changed)
    - Teams adaptive card alerts with zone-based severity classification
    - SHA-256 evidence export with integrity hashing for FINRA/SEC examination support

    **Deployable Solution:** [conditional-access-automation](https://github.com/judeper/FSI-AgentGov-Solutions/tree/main/conditional-access-automation) provides PowerShell deployment scripts, Azure Automation runbook wrappers, and Power Automate flow definitions.

---

## Implementation Playbooks

!!! info "Step-by-Step Implementation"

    This control has detailed playbooks for implementation, automation, testing, and troubleshooting:

    - [Portal Walkthrough](../../playbooks/control-implementations/1.11/portal-walkthrough.md) — Step-by-step portal configuration
    - [PowerShell Setup](../../playbooks/control-implementations/1.11/powershell-setup.md) — Automation scripts
    - [Verification & Testing](../../playbooks/control-implementations/1.11/verification-testing.md) — Test cases and evidence collection
    - [Troubleshooting](../../playbooks/control-implementations/1.11/troubleshooting.md) — Common issues and resolutions

---

## Verification Criteria

Confirm control effectiveness by verifying:

1. Conditional Access policies are enabled for agent creators / makers / admins, with **Authentication Strengths = Phishing-resistant MFA** for Zone 3.
2. Break-glass procedure verified: two cloud-only emergency accounts exist, are excluded only from policies that could lock the tenant out (not from phishing-resistant requirement), have FIDO2 keys in physical safes, have Sentinel sign-in alerts wired to SOC, and have a documented quarterly sign-in test (alternating accounts) recorded in the WSP / SOX 404 evidence set.
3. CA `What if` tool confirms break-glass accounts are not blocked by any tenant CA policy and confirms expected enforcement for representative maker / admin / agent identities in each zone.
4. Phishing-resistant authentication methods are enabled in the Authentication Methods policy with FIDO2 / device-bound passkey / CBA / WHfB cloud Kerberos trust; **synced passkeys do not satisfy AAL3** — verified.
5. Continuous Access Evaluation (CAE) is enabled tenant-wide; sign-in logs for Copilot / Copilot Studio / Graph clients show `Continuous access evaluation = True`.
6. Where supported native clients are in use, a Token Protection pilot CA policy is in `Report-only` for Zone 3 admin populations, with unsupported browser and mobile gaps documented as compensating controls. **Token Protection is not currently supported for browser-based applications including most Copilot Studio and Power Platform authoring portals** — do not assume TP protects browser maker sessions.
7. Sign-in frequency CA Session control is set to ≤ 4 hours (Zone 3) / ≤ 12 hours (Zone 2) for Copilot Studio / Power Platform admin portals; **Persistent browser session = Never persistent** for Zone 3 maker portals.
8. Token theft detection CA policy on `User risk = High` is enabled and tested with a synthetic risky-user assignment.
9. PIM is configured for AI / Power Platform / Purview directory roles with **MFA on activation via Conditional Access authentication context** (not session-token reuse), step-up to phishing-resistant for Zone 3, justification required, and approval workflow with backup approvers.
10. **Workload Identities Premium** licensing covers every **single-tenant service principal** and **Entra Agent ID**–registered agent in scope; CA WID policies are enforcing (not just authored) — confirmed via a synthetic SP sign-in. **Managed identities are not currently covered by CA WID policy enforcement** and should be governed through least-privilege permissions, named-location restrictions where applicable, access reviews, and sign-in monitoring until Microsoft extends coverage.
11. Agent-specific CA policies are demonstrably distinct from human-user CA policies; Zone 2/3 agents are covered either per-agent or via the `AgentZone` custom security attribute.
12. Microsoft-managed CA policies (filtered by `Source = Microsoft`) include the high-risk agent / workload-identity baseline, and it shows `On` (not `Report-only`).
13. Identity Protection **Risky workload identities** report is reviewed weekly for Zone 2/3; dismissals have documented investigation records in ITSM.
14. Sovereign-cloud parity confirmed for the deployment cloud (Commercial / GCC / GCC High / DoD): Entra Agent ID availability, CA WID + Workload Identities Premium SKU GA date, FIDO2 / CBA attestation roots, CAE, Token Protection. Any gap documented as a compensating control.
15. Microsoft Sentinel **Conditional Access Insights and Reporting** workbook is deployed and reviewed before any CA policy is promoted from `Report-only` to `On`.
16. Sign-in logs are streamed to Sentinel / Log Analytics with retention aligned to Control 1.7 / 1.19 (≥ 6 years for recordkeeping-scope agents per SEC 17a-4(b)(4)).

---

## Additional Resources

- [Microsoft Learn: Conditional Access Overview](https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview)
- [Microsoft Learn: Microsoft Entra Agent ID](https://learn.microsoft.com/en-us/entra/agent-id/what-is-microsoft-entra-agent-id)
- [Microsoft Learn: Authentication Methods](https://learn.microsoft.com/en-us/entra/identity/authentication/overview-authentication)
- [Microsoft Learn: Governing Agent Identities](https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview)

### Agent Essentials & Blueprint (Preview)

> **Note:** The following resources are preview documentation and may change.

- [Microsoft Learn: Agent 365 Blueprint (Preview)](https://learn.microsoft.com/en-us/microsoft-365/copilot/agent-essentials/m365-agents-blueprint) - 3-phase deployment blueprint with identity integration
- [Microsoft Learn: Agent Deployment Checklist (Preview)](https://learn.microsoft.com/en-us/microsoft-365/copilot/agent-essentials/m365-agents-checklist) - Category 1 covers access and availability policies
- [Agent Identity Architecture](../../framework/agent-identity-architecture.md) - Framework guidance on Agent ID vs. Blueprint architecture decisions

---

*Updated: May 2026 | Version: v1.6.2 | UI Verification Status: Current (re-verified May 2026)*
