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 Regulatory Notice 21-18 (cybersecurity), FINRA 25-07, 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 2011-12 / Federal Reserve SR 11-7 (Model Risk Management — authentication controls on model-serving endpoints)
Last UI Verified: April 2026
Governance Levels: Baseline / Recommended / Regulated

Agent 365 Architecture Update

Entra Agent ID (Public Preview) 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. See Unified Agent Governance for agent Conditional Access policy examples and configuration guidance.

Agent Registry Visibility (February 2026): Copilot Studio agents are visible in the Agent 365 registry. Microsoft Foundry agents are expected at GA. 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.

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 (preview) 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 4511 / 25-07 / 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 Notice 25-07 (March 2025) is a workplace modernization RFC that touches on AI workflows and is cited here as contextual industry consultation only. 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 2011-12 / Fed 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 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 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

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 Frontier program enrollment (preview) 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

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 Public Preview (Frontier) Limited preview — confirm enrollment Not yet available (early 2026) Not yet available (early 2026)
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. 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 (Preview)

Preview Feature

Microsoft Entra Agent ID is currently in preview. This information relates to a prerelease product that may be substantially modified before release. These features require Frontier program enrollment. Entra Agent ID rides on top of CA for Workload Identities (above) — the Workload Identities Premium SKU is a prerequisite even during preview.

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 (Preview)

Agent-specific CA policies extend the standard Entra CA framework to workload identities representing AI agents. The following capabilities are available under Frontier enrollment:

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
Frontier program enrollment confirmed 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, 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 (preview); 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 4511 / 25-07, 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. 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

Agent Essentials & Blueprint (Preview)

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

Updated: April 2026 | Version: v1.4.0 | UI Verification Status: Current (re-verified April 2026)