# yaml-language-server: $schema=../../../../schema/control.schema.json
id: CB-M365-AUTH-004
title: Require phishing-resistant MFA for administrative roles
finding:
  title: Administrators can sign in with MFA methods that can be phished
  description: An attacker who relays a password and a push or code prompt through a fake sign-in page gets a privileged session on the tenant.
status: active
profiles: [baseline]
risk:
  severity: critical
assessment: manual
tags: [mfa, phishing-resistant, conditional-access, privileged-access, passkeys]

applicability:
  requires:
    - "Microsoft Entra ID P1"

description: |
  A Conditional Access policy requires the built-in **Phishing-resistant MFA** authentication
  strength for every user holding a privileged directory role, on all resources. Accepted methods
  are passkeys (FIDO2 security keys or Microsoft Authenticator passkeys), Windows Hello for
  Business and certificate-based authentication with multifactor binding.

  The policy includes at least these built-in roles: Global Administrator, Privileged Role
  Administrator, Privileged Authentication Administrator, Security Administrator, Conditional
  Access Administrator, Exchange Administrator, SharePoint Administrator, User Administrator,
  Application Administrator, Cloud Application Administrator, Authentication Administrator,
  Helpdesk Administrator, Password Administrator, Billing Administrator and Hybrid Identity
  Administrator. It excludes only the emergency access accounts (CB-M365-ADMIN-002).

  This control covers plain MFA for administrators: a phishing-resistant method is a stronger form
  of MFA.
rationale: |
  Push notifications, one-time codes, SMS and voice calls can all be relayed in real time by an
  adversary-in-the-middle phishing kit, which then steals the session cookie. Phishing-resistant
  methods are bound to the sign-in origin, so a fake page cannot use them. Administrator accounts
  are the first target of these kits because one session is enough to take over the tenant.
impact: |
  Every administrator must register a passkey, a security key or Windows Hello for Business before
  the policy is enforced, otherwise they are locked out. Hand out a Temporary Access Pass to
  register the first method (CB-M365-AUTH-017). Administrators who also work from shared or
  non-Windows devices need a roaming security key or an Authenticator passkey. External
  authentication methods cannot be combined with authentication strengths.
notes: |
  Conditional Access only applies to built-in roles assigned at directory scope. Roles scoped to
  an administrative unit and custom roles are not covered: protect those accounts with a group
  included in the same policy. With Privileged Identity Management, the policy applies once the
  role is active; also require MFA on activation in the role settings.

audit:
  manual: |
    1. Sign in to the Microsoft Entra admin center (https://entra.microsoft.com) as at least a
       Security Reader.
    2. Browse to **Entra ID** > **Conditional Access** > **Policies**.
    3. Find a policy with **State** set to **On** (not Report-only) where:
       - **Users** > **Include** lists **Directory roles** with at least the roles above;
       - **Users** > **Exclude** contains only the emergency access accounts or their group;
       - **Target resources** includes **All resources**, without exclusions;
       - **Grant** is **Require authentication strength** set to **Phishing-resistant MFA** (or a
         custom strength that only allows passkeys, Windows Hello for Business or multifactor
         certificates).
    4. Browse to **Entra ID** > **Monitoring & health** > **Sign-in logs**, filter on an
       administrator, open a recent interactive sign-in and check under **Conditional Access**
       that the policy shows **Success**.
    5. Fail if no such policy exists, if it is in Report-only or Off, or if a privileged role from
       the list is missing.

remediation:
  manual: |
    1. Make sure every administrator has registered a phishing-resistant method: browse to
       **Entra ID** > **Authentication methods** > **User registration details** and filter on the
       administrators. Issue a Temporary Access Pass to those who have none.
    2. Browse to **Entra ID** > **Conditional Access** > **Policies** and select **New policy**.
    3. Name it, for example `ADM - Require phishing-resistant MFA`.
    4. **Users** > **Include** > **Select users and groups** > **Directory roles**: select the roles
       listed above. **Exclude**: select the emergency access accounts.
    5. **Target resources** > **Resources** > **Include**: **All resources**.
    6. **Grant** > **Grant access** > **Require authentication strength** > **Phishing-resistant
       MFA**.
    7. Set **Enable policy** to **Report-only**, save, and review the sign-in logs for a few days
       with the **Report-only** filter.
    8. Switch **Enable policy** to **On**.
  rollback: |
    Set the policy to **Report-only** or **Off**. Sign in with an emergency access account if no
    administrator can sign in anymore.

references:
  - title: Require phishing-resistant multifactor authentication for administrators
    url: https://learn.microsoft.com/entra/identity/conditional-access/policy-admin-phish-resistant-mfa
    publisher: Microsoft
    kind: vendor-doc
    accessed: 2026-10-24
  - title: Conditional Access authentication strengths
    url: https://learn.microsoft.com/entra/identity/authentication/concept-authentication-strengths
    publisher: Microsoft
    kind: vendor-doc
    accessed: 2026-10-24
  - title: Baseline security mode settings
    url: https://learn.microsoft.com/microsoft-365/baseline-security-mode/baseline-security-mode-settings
    publisher: Microsoft
    kind: vendor-doc
    accessed: 2026-10-24
mappings:
  - framework: cis-m365
    framework_version: "7.0.0"
    id: "5.2.2.1"
    relation: stricter
    note: CIS asks for any MFA method for administrators; ours requires a phishing-resistant one.
  - framework: cis-m365
    framework_version: "7.0.0"
    id: "5.2.2.5"
    relation: equivalent
  - framework: cisa-scuba-m365
    framework_version: "2.0.0"
    id: MS.AAD.3.6v1
    relation: equivalent
  - framework: anssi-admin
    framework_version: "3.0"
    id: "R36"
    relation: stricter
    note: ANSSI recommends two factors for administration; ours requires phishing-resistant factors.
  - framework: anssi-mfa
    framework_version: "2.0"
    id: "R2"
    relation: partial
    note: Applied to administrators only; CB-M365-AUTH-005 extends it to every user.
  - framework: nist-800-53r5
    framework_version: "5.1.1"
    id: IA-2(1)
    relation: related
  - framework: nist-800-53r5
    framework_version: "5.1.1"
    id: IA-2(6)
    relation: related
threats:
  - framework: mitre-attack
    id: T1557
  - framework: mitre-attack
    id: T1539
  - framework: mitre-attack
    id: T1078.004
related_controls:
  - id: CB-M365-AUTH-005
    type: related
  - id: CB-M365-AUTH-015
    type: requires
  - id: CB-M365-AUTH-003
    type: related
  - id: CB-M365-AUTH-017
    type: related
  - id: CB-M365-AUTH-024
    type: related
  - id: CB-M365-ADMIN-002
    type: related
  - id: CB-M365-AUTH-035
    type: related
  - id: CB-M365-ADMIN-001
    type: related
  - id: CB-M365-ADMIN-016
    type: related
  - id: CB-M365-DEVICE-007
    type: related

authors:
  - name: Alice
    github: Sn0wAlice
introduced_in: 0.1.0
created: 2026-10-24
updated: 2026-10-24