MFA conditional access under Cyber Essentials v3.3: what works, what fails

Conditional Access can enforce MFA across cloud services, but a policy name or registration report does not establish that the intended users are protected. Review the resulting authentication, including exclusions, session claims and recovery routes.

Read the MFA pillar for the overall baseline.

NCSC v3.3 requires MFA wherever available and always for cloud-service authentication. It does not introduce a universal new MFA prompt at every sign-in, a twelve-hour maximum session or an eight-to-twelve-hour token lifetime.

A valid existing MFA-authenticated session may satisfy a policy without prompting again. The important distinction is between verified MFA carried by a session or claim and a password-only route that bypasses required MFA.

• Target the intended users and in-scope cloud resources.
• Require effective MFA and inspect the authentication result for representative users.
• Check ordinary users, administrators, guests, direct service access and recovery.
• Identify technical identities separately from human sign-in.
• Confirm that report-only policies have been enabled before relying on them for assessment.

An office IP address is not itself an authentication factor. A trusted-location exclusion needs review if it permits password-only cloud authentication. Do not assume an exclusion fails solely because it exists, or passes solely because the network is internal: inspect the actual authentication and token state.

Choose session duration and reauthentication frequency according to risk, application behaviour and user needs. Cyber Essentials does not prescribe a universal twelve-hour timer or categorically prohibit remembering an MFA-authenticated session for ninety days.

Managed-device controls can strengthen access. They are not a universal requirement to buy Intune or pair every administrator with FIDO2.

A device identity plus a security key does not automatically prove two independent verification factors. Verify how the authenticator establishes possession and user verification, and how the service evaluates the resulting authentication. A compliant-device condition can be useful additional protection, but it does not replace the MFA grant control merely by being present.

1. Inventory the users and cloud resources to cover.

2. Design a broad require-MFA policy and review exclusions.

3. Prepare supported emergency access with strong independent authentication; do not leave an excluded cloud administrator password-only.

4. Use report-only mode to inspect impact, test users and recovery, then enable enforcement.

5. Block basic/legacy authentication paths that undermine the policy.

6. Add phishing-resistant administrator methods, device requirements and session controls where appropriate as hardening.

There is no staff-count threshold that mandates this exact design and no automatic first-pass guarantee from applying a template.

Review uncovered groups, password-only location bypasses, basic-authentication clients and human use of automation credentials. SMS is weaker than suitable alternatives, but it is not an automatic administrator failure under the scheme.

Use the effective configuration and sign-in evidence to identify gaps in your own environment; a published pass-rate percentage is not a substitute for those checks.

Provide the effective policy summary, relevant sign-in results and an explanation of exclusions and recovery. Registration reports and session settings are supporting context. They do not replace evidence of effective authentication for the required services.

For Microsoft-specific setup and emergency access, see the Microsoft 365 guide and Microsoft's emergency-access guidance.

Check what the policies actually enforce, keep rollout exclusions controlled, and test recovery safely. Separate your stronger device, factor and session choices from the Cyber Essentials minimum.

Start Cyber Essentials | Buy CE Micro £299.99 | MFA pillar