Skip to content

Control 1.11: Conditional Access and Phishing-Resistant MFA

Control ID: 1.11
Pillar: Security
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)
Last UI Verified: May 2026
Governance Levels: Baseline / Recommended / Regulated

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); 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). See Unified Agent Governance 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 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 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.

Frontier program and Agent 365 coexistence

Microsoft's Frontier program (an early-access program; the Microsoft 365 E7 SKU bundles Agent 365) 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 and the Agent 365 admin 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.

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:

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).
  • 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.

Automation Available

Companion solutions in FSI-AgentGov-Solutions:

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 (Microsoft recommends migrating to cloud Kerberos trust; see migration guide)); 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

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 solution for Service Principal CA policy templates.

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

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. 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.

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

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); 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). 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.

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:

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:

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:

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.

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.

When to Use Agent ID Only

  • Zone 1 agents with simple identity requirements
  • Single-tenant deployments with limited scale
  • Direct identity assignment via Entra
  • 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.

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 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 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 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
Control Relationship
1.4 - Advanced Connector Policies Connector access control complements CA scoping for Power Platform actions
1.5 - DLP and Sensitivity Labels DLP-for-Copilot enforcement assumes the user is authenticated under the right CA posture
1.7 - Audit Logging Sign-in logs and CA evaluation events are the join key for CopilotInteraction and incident investigation
1.12 - Insider Risk Detection Risky-user signal feeds CA User risk = High policy; Token theft detection is a Zone 3 trigger
1.19 - eDiscovery for Agent Interactions Sign-in logs are evidence preserved under hold for FINRA 8210 / SEC 17a-4(b)(4) production
1.21 - Adversarial Input Logging 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 Validates CA policy effectiveness via What-If, sampling gates, and report-only soak before promotion
2.8 - Access Control and Segregation of Duties 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 1.11 governs CA session frequency; 2.22 governs application-level inactivity at the PPAC layer
2.26 - Entra Agent ID Identity Governance Lifecycle companion to agent CA: agent provisioning, sponsorship, and deprovisioning that underpins CA policy targeting
3.1 - Agent Inventory 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 Provides unified visibility into how the CA posture described here applies across agent types and platforms
3.6 - Orphaned Agent Detection and Remediation Orphaned agents break the sponsor/owner accountability model that this control assumes for Zone 2 and Zone 3 governance
3.8 - Copilot Hub Cross-platform visibility into CA enforcement posture for all agent types

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 provides PowerShell deployment scripts, Azure Automation runbook wrappers, and Power Automate flow definitions.

Implementation Playbooks

Step-by-Step Implementation

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

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. Preview feature gaps (Entra Agent ID availability, CA WID + Workload Identities Premium SKU GA date, FIDO2 / CBA attestation roots, CAE, Token Protection) are documented as compensating controls where applicable.
  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

Agent Essentials & Blueprint (Preview)

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

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