Evidential Readiness Blueprint: Mapping Multi-Cloud Access Controls to Cyber Essentials Audit Requirements
WHEN THE AUDITOR ASKED FOR EVIDENCE, THE ROOM WENT QUIET
The Entra admin had MFA “turned on.”
The AWS engineer had SCPs “somewhere in Org.”
The MSP swore their techs “always” used conditional access.
None of it mattered, because nobody could prove any of it in a way that matched the Cyber Essentials Plus test specification. What followed was a frantic hunt through portals, half-working PowerShell scripts, and missing screenshots.
This article shows how to avoid that moment. You’ll build a practical evidential readiness blueprint that maps real multi‑cloud access controls to Cyber Essentials and Cyber Essentials Plus requirements—so when the assessor asks, you are ready in seconds, not weeks.
What you’ll learn
- How Cyber Essentials v3.3 and Cyber Essentials Plus actually test access control and MFA in cloud environments
- How to design Microsoft Entra ID and AWS access controls that are natively aligned to v3.3 (Danzell) requirements
- Which specific logs, reports, and configuration artefacts auditors expect as evidence—and how to generate them on demand
- How to automate continuous evidence capture across Entra ID and AWS using Config, logs, and APIs
- How to handle tricky scenarios: third‑party admins, MSPs, BYOD, and shared SaaS platforms
- The counter‑intuitive governance shift hidden inside the 2026 update that will change how you prepare for audits
Cyber Essentials v3.3: What Auditors Will Actually Test
Cyber Essentials v3.3, effective from April 2026, moves from “best effort” to hard, measurable access‑control rules. For multi‑cloud teams, that means every identity control in Entra ID, AWS IAM and SaaS must be designed with explicit, testable evidence in mind.
In practice, three themes dominate: uncompromising MFA on all cloud services, rigorous vulnerability management (14‑day windows), and much tighter scoping and legal accountability around what is in scope.
The access‑control bar in 2026
Key aspects relevant to multi‑cloud access:
-
MFA is zero‑tolerance for cloud
Under Danzell v3.3, if any cloud service that processes organisational data offers MFA and you have not enabled it, the assessment is an automatic fail—regardless of whether MFA is free or a paid add‑on. -
Cloud services cannot be scoped out
v3.3 formally defines “cloud service” as any on‑demand, internet‑accessible service on shared infrastructure that stores or processes org data. These must be in scope—Microsoft 365, Google Workspace, CRM, ticketing, RMM tools, etc. -
Passwordless is explicitly encouraged
The minimum password length moves to 12 characters, but the direction of travel is passwordless: passkeys and FIDO2 authenticators are called out as preferred MFA, and recognised as meeting MFA requirements. -
Patch and vulnerability fixes have auto‑fail timelines
Questions A6.4 and A6.5 require high‑risk/critical vulnerability fixes (OS, firmware, apps, browser extensions) within 14 days. Failure anywhere in the sampled estate is an auto‑fail, and CE+ now re‑sampled devices to kill “selective patching”. -
Scoping transparency and legal accountability
You must list all in-scope legal entities, declare excluded infrastructure (privately), and a director must sign that controls are maintained throughout the certification period—not just on audit day.
Key Takeaway
For access control, Cyber Essentials v3.3 is no longer about “having MFA”. It is about provably enforcing and maintaining MFA and secure configuration across all cloud services and privileged identities.
For multi‑cloud architects, the implication is clear: design Entra ID, AWS and SaaS controls so that they naturally emit the evidence the Cyber Essentials Plus Test Specification relies on—rather than retro‑fitting screenshots for each audit.
Designing Multi‑Cloud Access Controls Aligned to Cyber Essentials
To meet v3.3 cleanly across Entra ID, AWS, and other SaaS platforms, build around a small set of design principles. These principles are platform‑agnostic and translate directly into testable controls.
Principle 1: MFA everywhere it is available
Under v3.3/Danzell:
- MFA is mandatory for:
- All administrative accounts
- Any user accounts accessible from the internet
- All cloud services where MFA exists, even if it’s a premium feature
Practically:
- In Entra ID, use Conditional Access to require MFA for:
- All users for cloud apps in scope (M365, line‑of‑business SaaS)
- Especially for CISA’s eight highly privileged roles (Global Admin, Exchange Admin, etc.)
- In AWS, combine:
- IAM MFA for console users, enforced via AWS Config rules (
iam-user-mfa-enabled) - Preventative SCPs that deny critical actions if
aws:MultiFactorAuthPresentis false (noting SCPs do not apply to the Org management/root account)
- IAM MFA for console users, enforced via AWS Config rules (
Principle 2: Prefer phishing‑resistant and passwordless methods
Cyber Essentials and CISA guidance converge on phishing‑resistant MFA:
- In Entra ID:
- FIDO2 security keys and device‑bound passkeys
- Windows Hello for Business (device‑bound biometrics/PIN)
- Certificate‑Based Authentication (CBA) with PIV/CAC for regulated environments
These are explicitly recognised as MFA within Cyber Essentials, and dramatically reduce credential‑theft risk.
Principle 3: Separate admin from user identities
Cyber Essentials mandates dedicated administrative accounts that:
- Are separate from day‑to‑day user accounts
- Do not hold active licences granting personal mailboxes or business data access on the admin identity itself
So, for example:
- A Microsoft 365 Exchange admin account should not have an Exchange Online licence or user mailbox.
- AWS break‑glass and admin roles should be assumed from standard user identities with MFA, not used as permanent working accounts.
Mini‑Checklist – Access‑Control Design Targets
- Every cloud service in the SaaS register has MFA enabled for all users
- All admin accounts are separate from user accounts and unlicensed for business data
- At least one phishing‑resistant MFA method is available and promoted to users
- Legacy/basic auth is blocked everywhere it can bypass MFA
- Root/Org‑level accounts (Entra break‑glass, AWS root) have strong, hardware‑backed MFA
With principles set, the next step is cloud‑specific implementation and evidence.
Proving Control Effectiveness in Microsoft Entra ID
Entra ID is where most Cyber Essentials scope lives: Microsoft 365, Azure, and often SSO for third‑party SaaS. The good news: almost everything auditors care about can be evidenced with first‑party reports and Conditional Access artefacts.
Step 1: Design conditional access rather than per‑user MFA
Microsoft is actively migrating from legacy per‑user MFA to Conditional Access policies (requiring Entra ID P1/P2). For Cyber Essentials purposes, Conditional Access better expresses your intent and is easier to evidence:
-
Block legacy authentication
Create policies targeting “Exchange ActiveSync clients” and “Other clients” and set access to Block. This aligns with CISA MS.AAD.1.1v1 and closes MFA‑bypass paths. -
Require MFA for cloud apps
Policies that:- Target All users (with scoped exclusions only for break‑glass accounts)
- Cover All cloud apps or a clearly documented subset that maps to the SaaS register
- Enforce MFA or stronger conditions (e.g., compliant device + MFA)
-
Privileged roles baseline
Use role‑based policies to enforce stricter conditions (phishing‑resistant MFA, device compliance) on Global Admin, Exchange Admin, SharePoint Admin, etc.
Always roll out new policies in Report‑only mode first and validate with the “What If” tool and Conditional Access insights to avoid lockouts.
Pro Tip
Keep a version‑controlled export of Conditional Access policies (JSON or PowerShell export) and a human‑readable matrix mapping each policy to specific Cyber Essentials controls. This doubles as your audit evidence and design documentation.
Step 2: Evidence MFA and passwordless registration
For Cyber Essentials and CE+ you must show MFA is implemented, not just intended.
Use Entra’s built‑in reporting:
-
Portal reporting (no code)
- Entra admin centre → Authentication methods → User registration details
- Shows: registered methods, default MFA, passwordless readiness, and Authenticator Lite status (“Microsoft Authenticator (in Outlook)”)
-
Graph‑based exports (for large tenants)
- Use
Get-MgBetaReportAuthenticationMethodUserRegistrationDetail -Allto bulk extract:UserPrincipalNameMethodsRegistered(FIDO2, Authenticator, SMS, etc.)IsMfaCapable,IsSsprCapable
- Export to CSV and keep as dated evidence snapshots.
- Use
Be aware of Restricted Management Administrative Units: while tenant-wide reporting captures these users, modifying their methods requires explicitly delegated admins; otherwise, even Global Admins will receive 403 Forbidden. Design management scripts with RMAU boundaries in mind.
Step 3: Evidence actual MFA usage
Registered methods are not enough. Entra only keeps MFA sign‑in data for 30 days, so you need a process:
- In Entra admin centre, go to Sign‑in logs → filter for interactive sign‑ins with successful Conditional Access / MFA.
- Export CSV (≤250k records), manually remove the duplicate “incoming token type” column before
Import-CSVin PowerShell. - Summarise by user, MFA method, and date range for audit packs.
Where Entra ID Protection (P2) is licensed, configure policies to:
- Block high‑risk users and sign‑ins
- Send alerts to security admins
Export risk detection reports as additional evidence of ongoing monitoring.
Key Takeaway
For Entra ID, your evidential stack is: Conditional Access policy exports, Authentication Methods registration reports, 30‑day MFA usage logs, and (optionally) risk‑based protection reports. Together they prove design, registration, and live enforcement.
Proving Control Effectiveness in AWS
AWS is often in scope both as a platform you manage and as a supplier with its own Cyber Essentials Plus certification. You must evidence your own IAM controls, and, where relevant, rely on AWS’s certifications through AWS Artifact.
Step 1: Hardening and evidencing IAM
For Cyber Essentials, focus on:
-
Root account
- No active access keys
- MFA mandatory (ideally hardware‑based)
-
IAM users
- MFA enforced for all console users
- No long‑lived access keys:
- Rotate keys at least every 90 days
- Flag unused keys (no usage >90 days) for deactivation
Use:
-
IAM credential reports (CSV snapshots, cached for 4 hours):
- Fields:
password_enabled,mfa_active,access_key_1_last_rotated,access_key_1_last_used_date, etc. - Form the backbone of periodic evidence packs.
- Fields:
-
AWS Config managed rule
iam-user-mfa-enabled- Continuously monitors MFA status across IAM users.
- Non‑compliance can trigger Lambda remediation or SNS notifications.
- This decouples discovery from remediation, avoiding Lambda timeout problems for large user populations.
Pro Tip
Don’t write monolithic Lambda loops over all users; they will eventually hit the 15‑minute limit. Use AWS Config managed rules for detection, or an orchestrator Lambda that writes user lists to S3 and fans out chunked processing across concurrent Lambdas.
Step 2: Preventative enforcement with SCPs
Within AWS Organizations:
- Use Service Control Policies to deny:
- Sensitive API calls (e.g.,
iam:*,kms:*,organizations:*) - Or even console access
whenaws:MultiFactorAuthPresentisfalse.
- Sensitive API calls (e.g.,
Limitations:
- SCPs do not apply to the Org management/root account. You still need process, break‑glass controls and Config/Lambda monitoring for that identity.
Document your SCP library and keep JSON exports as part of your audit kit. Map each SCP to explicit Cyber Essentials controls (e.g., “prevents administrative changes without MFA”).
Step 3: Show platform‑level assurance with AWS Artifact
Where you rely on AWS’s own Cyber Essentials Plus certification:
- Use AWS Artifact in the AWS Management Console to download:
- The current Cyber Essentials Plus certificate
- Related ISO 27001 / 27017 / 27018 and CSA STAR attestations
These documents prove that the underlying infrastructure meets UK‑recognised baselines. However, Cyber Essentials is clear: this does not remove your responsibility for identity, access and data controls in your tenant.
Key Takeaway
For AWS, pair your own IAM/Config/SCP evidence with AWS Artifact certificates. One proves how you manage identities; the other proves the platform’s own posture.
Building an Evidential Readiness Pipeline Across Clouds
Manually assembling evidence every year is brittle. Cyber Essentials v3.3 also moves the emphasis to continuous compliance. The answer is an evidential pipeline that continuously captures, normalises and stores proof.
Step 1: Define an evidence catalogue per requirement
For each relevant Cyber Essentials control (especially access control and vulnerability management), define:
- Control objective – e.g., “MFA enforced for all admin and cloud‑accessible accounts”
- Cloud implementation – Entra Conditional Access, AWS Config rule, SaaS MFA configs
- Primary evidence sources:
- Config exports
- Scheduled CSV reports
- Screenshots only where APIs are unavailable
- Sampling strategy for CE+ (device sampling, admin account demos, etc.)
Step 2: Automate evidence collection
Examples:
-
Entra ID
- Scheduled scripts (Graph PowerShell) exporting:
- Authentication method registrations
- MFA usage summaries (last 30 days)
- Conditional Access policy definitions
- Store results in a secure evidence repository (SharePoint, dedicated storage account).
- Scheduled scripts (Graph PowerShell) exporting:
-
AWS
-
Scheduled Lambda to:
- Generate and retrieve IAM credential reports
- Evaluate against rotation and usage policies
- Notify via SNS/Slack when critical violations appear
- Archive every report for drift analysis
-
Enable AWS Config:
- Use
iam-user-mfa-enabledand other managed rules relevant to identity and network security - Configure Delivery Channels to an S3 bucket with lifecycle policies for long‑term retention.
- Use
-
Mini‑Checklist – Evidential Pipeline
- Evidence catalogue mapped to Cyber Essentials “Requirements for IT Infrastructure” sections
- Automated exports from Entra and AWS at least monthly
- Evidence stored immutably with timestamps (read‑only area, object lock, or equivalent)
- Scripts and pipelines under source control, change‑managed like application code
- Dry‑run “mock audit” at least once a year before renewal
This pipeline mindset aligns neatly with the updated requirement that directors attest to ongoing compliance, not one‑day snapshots.
Working with Third Parties and BYOD Without Losing Compliance
Real‑world environments are messy: MSPs hold admin accounts, staff use personal devices, and guest networks exist. Cyber Essentials has precise views on where responsibility sits and what must be evidenced.
Third‑party admins and MSPs
Key rules:
- Devices owned by external providers are out of scope for your assessment.
- But you remain fully responsible for ensuring Cyber Essentials controls (like MFA) are applied to administrative accounts they use on your systems.
Practical steps:
-
Contractual enforcement
- Bake Cyber Essentials and MFA requirements into contracts/SLAs.
- Require MSPs to hold their own Cyber Essentials (or CE+) certification; verify via the IASME registry.
-
Evidence for CE+
- For third‑party‑managed admin accounts, auditors accept:
- Live screen‑share of an MSP engineer logging in and hitting an MFA prompt, or
- Screen recordings of the login → password → MFA flow.
- For third‑party‑managed admin accounts, auditors accept:
Key Takeaway
Cyber Essentials is a technical framework, not a full risk framework like ISO 27001. Supply‑chain and MSP risk is handled by contracts and independent certifications, not by trying to pull their devices into your scope.
BYOD and remote work
Guidance is strict but pragmatic:
- In scope: Personal devices that access work data or services (e‑mail, files, SaaS).
- Out of scope: Devices used only for SMS, voice calls, or MFA apps (no data access).
Where BYOD is in scope, Cyber Essentials expects:
- Supported OS and apps, updated within 14 days
- Firewalls enabled
- Auto screen lock with ≥6‑digit PIN or biometrics
- No rooting/jailbreaking
Advanced risk reduction:
- Container / managed apps that isolate corporate data
- MDM solutions enforcing policy on enrolled devices
- Desktop virtualisation (Citrix, etc.) to keep data off personal hardware
From an evidential standpoint, MDM reports and configuration baselines are your strongest artefacts for BYOD.
The Counter‑Intuitive Lesson Most People Miss
The most significant change in the Cyber Essentials Danzell era is not technical—it is governance.
Historically, many organisations treated Cyber Essentials as an annual “badge”. Technical teams scrambled just before renewal, patched devices in the sample, toggled MFA for a subset of users, and collected screenshots. Once the certificate was issued, normal (often weaker) practice resumed.
v3.3 quietly kills that model:
- The director’s declaration now explicitly states a duty to maintain controls for the entire certificate period.
- CE+ methodology has been tightened so that:
- If the first sample fails patching checks, a new random sample plus the original are retested.
- A second failure revokes the verified self‑assessment certificate.
- Cloud services, admin accounts and high‑risk updates have auto‑fail semantics.
The counter‑intuitive reality:
Evidential readiness is primarily a board‑level discipline, not an engineering exercise.
If governance does not mandate that:
- Conditional Access and SCP changes go through change control,
- Evidence exports run on schedule,
- MSPs are contractually bound to Cyber Essentials, and
- BYOD/remote policies are enforced technically,
then no amount of last‑minute engineering effort will save an audit where the assessor is allowed to choose fresh random samples and demand live demonstrations.
For multi‑cloud leaders, the real blueprint is to embed Cyber Essentials into standard operating procedures, and design Entra ID and AWS architectures that naturally produce the evidence directors are signing for.
Key Terms: Mini‑Glossary
- Cyber Essentials – A UK government‑backed technical control framework defining baseline defences against common internet‑borne threats.
- Cyber Essentials Plus (CE+) – The higher tier of Cyber Essentials requiring independent hands‑on testing and technical verification.
- Danzell v3.3 – The Cyber Essentials Requirements for IT Infrastructure version effective from April 2026, with stricter MFA, cloud and patching rules.
- Conditional Access – Microsoft Entra ID’s policy engine that enforces access decisions (e.g., require MFA, block legacy auth) based on user, device and session context.
- AWS Config – An AWS service that records resource configurations over time and evaluates them against managed or custom compliance rules.
- IAM Credential Report – A CSV snapshot from AWS IAM listing all users and the status/age/usage of their passwords and access keys.
- Service Control Policy (SCP) – An AWS Organizations policy type that defines maximum allowed permissions for accounts, used to enforce preventative controls like MFA‑only actions.
- Phishing‑Resistant MFA – Authentication methods like FIDO2, CBA, and Windows Hello that cannot be easily phished or replayed because they rely on device‑bound cryptographic keys.
- Authentication Methods Report – Entra ID reporting view and Graph API output showing which MFA/passwordless methods each user has registered.
- AWS Artifact – A self‑service portal in the AWS console providing on‑demand access to AWS compliance reports and certifications.
FAQ
Does Cyber Essentials require specific MFA technologies (e.g., FIDO2), or just “any MFA”?
Cyber Essentials v3.3 recognises multiple MFA types, but strongly encourages passwordless and phishing‑resistant methods such as FIDO2 and passkeys. SMS and voice can still meet the letter of the control, but they are weaker and may be harder to justify to assessors as a long‑term strategy.
How do auditors verify that MFA is enabled on third‑party SaaS applications?
Typically through a combination of admin‑portal configuration screenshots, exportable security settings, and—during CE+—live demonstrations of admin logons showing the MFA prompt. If the SaaS uses Entra ID SSO, your Conditional Access policies and Entra MFA evidence often cover much of the requirement.
Are AWS IAM roles covered by IAM credential reports?
No. IAM credential reports only cover IAM users. Roles, their policies, and their usage must be audited via IAM Access Advisor (e.g., generate-service-last-accessed-details) and, where applicable, AWS Config rules. Design your evidence set to include both.
How often should evidential exports run to satisfy “ongoing compliance”?
The standard does not mandate a frequency, but monthly exports for access‑control evidence (MFA registration, Config evaluations, credential reports) are a pragmatic minimum. High‑risk environments often choose weekly or near‑real‑time monitoring with alerts for deviations.
Can we still pass Cyber Essentials if some legacy systems cannot support MFA?
For truly MFA‑incompatible systems, you must demonstrate strong compensating controls and strict segmentation, and these systems will be heavily scrutinised. For cloud services that offer MFA, however, v3.3 is explicit: if MFA exists and you have not enabled it, the result is an automatic fail.
How does Cyber Essentials treat personal devices used only for MFA apps?
If a personal device is used solely to receive MFA codes or approve app prompts and never accesses organisational e‑mail, files, or SaaS, it is out of scope. Once the device accesses work data or services, it becomes in scope and must comply with BYOD technical controls.
Conclusion: Turning Compliance into a First‑Class Architecture Outcome
The story that opened this article ends two ways.
In one version, teams scramble, generate ad‑hoc exports, and patch just enough devices to scrape through—until Danzell v3.3, random re‑sampling, and auto‑fail MFA rules expose the fragility of that approach.
In the better version, access control for Entra ID, AWS and SaaS was engineered from day one with Cyber Essentials in mind:
- MFA (preferably phishing‑resistant) is non‑negotiable on every cloud service.
- Conditional Access and SCPs enforce policy, while Config and logs provide continuous evidence.
- BYOD, MSPs and third‑party admins are bounded by technical controls and contracts.
- Automated pipelines export, store and version evidence so that CE+ audits become routine, not existential.
That is the Evidential Readiness Blueprint: treat Cyber Essentials not as an annual form, but as a design constraint for your multi‑cloud access architecture. Do that, and when the assessor asks, you will not just claim you are secure—you will be able to prove it.
