Cyber Essentials Access Control Without Passwords (UK)

Introduction: Why “access control without passwords” matters for Cyber Essentials (UK)

In the UK, Cyber Essentials access control is not a tick-box exercise; it is a concrete set of controls designed to stop the most common attacks that lead to account takeover, data exfiltration, and business disruption. Since April 2023, and carried forward into the April 28, 2025 “Willow” question set, the scheme has moved decisively toward stronger authentication, explicitly requiring multi-factor authentication (MFA) for all users of all cloud services in scope. That evolution reflects a simple truth: passwords fail in the real world, and they fail precisely where attackers operate—on the open internet. By removing passwords (or at least removing them from day-to-day use) and replacing them with phishing-resistant methods such as WWPass/WebAuthn passkeys or cryptographic authenticators, organisations materially reduce credential theft, adversary-in-the-middle attacks, and replay. From a Cyber Essentials perspective, this shift also simplifies compliance evidence, because it is far easier to prove that a login flow enforces strong, origin-bound cryptography than to prove that every user’s password meets policy and is never reused or phished. The UK’s National Cyber Security Centre (NCSC) and IASME have repeatedly signposted this direction of travel: MFA for cloud is mandatory, and guidance now emphasises choosing stronger, phishing-resistant MFA where practical.

The five Cyber Essentials control themes at a glance

Cyber Essentials groups its baseline defences into five control themes: firewalls, secure configuration, security update management, user access control, and malware protection. Access control is the thread that weaves through them all, because the boundary between “inside” and “outside” is now defined by identity as much as network perimeters. In practice, that means the technical configuration of devices and services must align tightly with your identity architecture. For example, if your cloud apps enforce phishing-resistant MFA but your laptops still auto-logon with cached passwords, you have a gap. If your firewalls allow inbound access to an admin interface but the admins don’t use separate privileged identities with step-up verification, you have a bigger gap. Cyber Essentials expects that organisations define scope clearly, implement the controls consistently within that scope, and provide evidence that each control is operating effectively. Access control is therefore the backbone: it governs who can sign in, with what assurance level, and what they can do once inside.

Where “User Access Control” and “Secure Configuration” intersect with authentication

“User Access Control” governs identity proofing, account issuance, privilege assignment, and revocation; “Secure Configuration” governs how devices, operating systems, and services are hardened so that only secure authentication methods are permitted and insecure defaults are disabled. When these two meet in the sign-in flow, you get outcomes that auditors can test: the OS login requires a device-bound factor (for example, Windows Hello for Business with a TPM-protected key and a biometric or PIN) and the cloud SSO requires phishing-resistant MFA before access to data. If your configuration allows password-only fallback, or relies on weak out-of-band codes, attackers will find it—and Cyber Essentials Plus testers may find it too. The NCSC’s guidance stresses the principle of least privilege and strong authentication tailored to the risk of the action being performed. This is exactly where conditional access policies, step-up rules, and phishing-resistant methods demonstrate that secure configuration and user access control are two sides of the same control.

What Cyber Essentials expects for Access Control

At minimum, Cyber Essentials expects that each user has a unique account; privileges are carefully controlled; default accounts or shared accounts are avoided; and administrative activities are performed with separate, hardened identities. For cloud services, MFA is required for all users—not just admins—and must be enforced uniformly across all in-scope services. Assessors will look for clear scoping, documented processes for joiners, movers, and leavers, and evidence that authentication strength matches exposure: internet-facing systems, remote access, and administrative interfaces must demand stronger factors. The “Willow” question set doesn’t radically change these expectations; it clarifies definitions and keeps the scheme aligned with modern working patterns. The direction is clear: fewer passwords, more cryptography, and consistent enforcement.

Scope: users, admins, service accounts, and third parties

A common cause of non-compliance is poorly defined scope. Your Cyber Essentials access control scope must include employees, contractors, temporary staff, and third parties who access organisational data or systems. It must also include service accounts used by software, scripts, and integrations, which are often over-privileged, never rotated, and rarely monitored. For cloud platforms, “all users” means exactly that: everyone authenticating to in-scope cloud services must use MFA. For service accounts, the expectation is not “MFA for robots” but tight scoping of privileges, non-interactive use, secrets held in secure stores, and strong rotation practices. Where vendors or partners require access, federate identities where possible so that your policies apply to them at sign-in. These are not optional hygiene measures; they are central to stopping initial access and lateral movement.

Least privilege & role design: mapping roles to privileges

Least privilege is the antidote to permission creep. Start with a role catalogue that mirrors real work: service desk agent, developer, finance analyst, HR partner, platform administrator. For each role, document the smallest set of entitlements required to perform essential tasks. Implement those entitlements through groups in your identity provider (IdP) and synchronise them to apps. Prohibit direct assignment of privileges to individuals except under break-glass conditions. In infrastructure clouds (AWS, Azure, GCP), encode least privilege as policies that grant only the actions and resources the role actually needs; avoid “*” wildcards; audit for privilege escalation paths. In SaaS, keep role templates lean: if a product’s “admin” role includes billing and user management, but a team only needs to manage content, create a custom role or use separate apps. Least privilege is not a one-time configuration; it is a governance loop tied to joiner–mover–leaver events and periodic recertification. The UK public sector guidance and NCSC cloud principles repeatedly underscore that granular access and least privilege reduce the blast radius of compromise and simplify assurance.

Joiner–Mover–Leaver: onboarding, changes, revocation

Failures in identity lifecycle are a silent source of risk. Onboarding must bind a real person to a real identity, issue the minimum roles required, and immediately enrol strong authenticators. Movers must trigger a role review, not a permission accretion: when someone changes department, their old role memberships should be removed as new ones are added, and their app access should be re-provisioned accordingly. Leavers must lose access the same day, preferably the same hour; their tokens should be revoked; their devices should be locked or wiped; and any long-lived credentials (API keys, service account secrets) associated with them should be rotated. For Cyber Essentials, an assessor will want to see these flows working in practice, not just in policy. Tying lifecycle to your IdP and SSO allows you to automate much of this, and it also enables conditional access to respond to status changes instantly.

Admin account separation & default-deny policies

Administrative privileges transform a phishing incident into an organisation-wide breach. That’s why separate administrative accounts are non-negotiable: admins perform privileged tasks only while signed in with a hardened admin identity, ideally from a privileged access workstation or managed device tier with elevated protections. Everyday work like email and browsing must never be carried out with the admin identity. Pair account separation with default-deny conditional access: require phishing-resistant MFA, restrict admin sign-ins to managed devices, prohibit legacy protocols, and demand step-up for high-impact actions such as changing MFA methods, altering SSO providers, or modifying conditional access itself. This pattern is endorsed across UK guidance and reduces both the probability and the impact of compromise.

Moving beyond passwords: phishing-resistant MFA

Passwordless is not a buzzword; it is a safety measure. Phishing-resistant MFA binds authentication to the legitimate origin and to the user’s device, rendering credential forwarding and replay attacks ineffective. In practice, this means WWPass/WebAuthn passkeys on platform authenticators and/or cross-platform security keys, and it can also include cryptographic authenticator systems that eliminate usernames and passwords entirely while preserving strong possession and user-verification factors. When you adopt phishing-resistant methods, support costs drop, user experience improves, and your Cyber Essentials evidence becomes simpler: you can show that the method itself is resistant to the very attacks the scheme is designed to prevent.

To make this real in an enterprise, many teams layer phishing-resistant MFA on top of their existing SSO rather than ripping and replacing identity. For example, organisations adopt passkeys for web and mobile access while issuing hardware security keys to admins and high-risk roles. Others implement cryptographic MFA that uses QR-mediated device binding with no shared secrets. If you’re comparing options, this overview of WWPass Multi-Factor Authentication is a helpful reference point for how a username-less, password-less approach can be deployed alongside, or instead of, classic factors while preserving user verification with biometrics or PIN.

Why passwords fail (phishing, replay, credential stuffing)

Passwords fail because humans are human and web protocols are permissive. People reuse credentials across work and personal services; attackers harvest those credentials from breaches and try them en masse in credential-stuffing attacks; adversaries set up look-alike domains and reverse-proxy phishing sites to forward real login sessions past SMS codes and app prompts; malware steals stored passwords; and support desks get tricked into resetting them. Even with strong composition rules and breached-password checks, the protocol still requires a user to send a secret to a server that a fake site can steal. That’s why modern guidance places less weight on “strong passwords” and more on authentication that’s bound to the device and the origin, such as passkeys or hardware-backed platform credentials. The NCSC’s phishing guidance and recent passkey commentary say the quiet part out loud: passwords are the weak link; origin-bound cryptography is the fix.

Phishing-resistant MFA options (WWPass/WebAuthn, smart cards)

There are three broad families to consider. First, WebAuthn passkeys using WWPass—either on platform authenticators embedded in laptops and phones or on roaming authenticators such as hardware security keys. These are explicitly classed as phishing-resistant by multiple national authorities. Second, cryptographic authenticators such as WWPass that remove usernames and passwords altogether and use device-bound secrets plus user verification (biometric/PIN) to authorise access; the login begins by proving possession and presence rather than by typing an identifier. Third, smart cards—still a strong option in Windows domains and high-assurance environments—especially when backed by a well-run PKI and used with dedicated admin workstations. For Cyber Essentials, what matters is that the method you choose is robust against phishing and hijacking and is enforced everywhere in scope.

When to use platform vs roaming authenticators (passkeys, security keys)

Platform authenticators (built into laptops and phones) are ideal for the majority of your workforce: they’re convenient, fast, and benefit from hardware protection like a TPM or Secure Enclave. They support discoverable credentials (resident passkeys) and integrate seamlessly with SSO. Roaming authenticators—hardware security keys—excel for shared-device scenarios, contractors, and especially for administrators who need a separate, portable high-assurance factor that’s not tied to the daily-driver device. Many organisations deploy both: platform passkeys for daily use, with a roaming key as a backup and for privileged sessions. The WWPass Alliance and platform vendor guidance describe these trade-offs plainly: use platform for ubiquity and UX; add roaming for portability, recovery, and high-risk roles.

Secure Configuration that supports passwordless

Passwordless falls over if devices are misconfigured. Harden your endpoints so that only approved authenticators can sign in and that password-only logins are disabled. On Windows, Windows Hello for Business should use hardware-backed keys and enforce user verification with biometric or PIN, with policy to require a compatible TPM and anti-spoofing for face recognition. On macOS and mobile, ensure that passkeys are enabled, screen-lock is mandatory, and biometric unlock requires a passcode fallback. For browsers, keep them updated to support modern WebAuthn features. Most importantly, set your IdP/SSO to refuse weaker fallback flows: disable legacy protocols, block basic authentication, and conditionally require phishing-resistant methods for sensitive apps or from risky networks and devices. These are secure-configuration decisions that transform policy into enforced reality.

Hardening identity providers and SSO with conditional access

Conditional access is how you express risk in code. Define policies that evaluate who is signing in, from which device, to which app, and under what conditions. Require phishing-resistant MFA for high-impact apps and admin roles; allow step-up only when needed; block unsupported devices and locations; and demand device compliance signals for access to sensitive data. Tie recovery paths to the same standard: changing a registered authenticator must itself require an already-trusted authenticator, not just email or SMS. Most IdPs let you integrate passkeys, security keys, and cryptographic authenticators alongside app-based OTP. If your existing SSO can’t deliver passwordless UX with phishing-resistant factors, consider adding a dedicated layer that does. For a practical perspective on moving to a single, modern login across estate, this deep-dive on passwordless SSO for web and mobile apps explains how to integrate passkeys and align them with zero-trust policies; WWPass SSO shows how an SSO can enforce username-less, password-less login with strong cryptography at the front door.

Device trust & OS login (biometrics, PIN, smart card)

Cyber Essentials places strong emphasis on the endpoint. If a device can be trivially unlocked, everything that follows is moot. Use device-bound credentials for OS login: Windows Hello for Business on Windows, passkeys/Touch ID/Face ID on Apple devices, and smart cards where required. Enforce a screen-lock and require user verification (biometric or PIN) that’s tied to a hardware-protected key. Biometrics are acceptable when correctly implemented because the biometric never leaves the device and only unlocks the local private key. This model gives you two factors at the OS boundary: something you have (the device/TPM) and something you are or know (biometric/PIN). When admins sign into privileged sessions, require an additional, separate authenticator—often a roaming security key or smart card—used only for admin work on managed, locked-down machines.

Cloud services: enforcing MFA for all cloud access

From a Cyber Essentials viewpoint, the rule is easy to state and essential to implement: enforce MFA for all users of all cloud services in scope. That means Microsoft 365, Google Workspace, Slack, Salesforce, developer platforms, backup portals, and any other SaaS that touches organisational data. Where a cloud service cannot support MFA natively, federate it behind your IdP so that your policies apply; where a service cannot support federation or MFA at all, treat it as an exception with a short-term plan to replace it. Test enforcement continuously: create a test user with no MFA to prove that access is blocked; review sign-in logs for legacy protocols and conditional-access failures; and make sure that self-service registration and recovery cannot downgrade the assurance of an account.

Implementing “Cyber Essentials access control” without passwords

A practical programme has three tracks running in parallel. The first is architecture: decide your IdP and SSO centre of gravity, choose your phishing-resistant authenticators, define your conditional access, and design your admin-tier model. The second is enrolment and recovery: build an enrolment flow that binds authenticators to users with high integrity, codify recovery so that it cannot be social-engineered, and pre-issue backup methods to the right people. The third is migration: move users and apps in waves, starting with lower-risk populations to iron out UX issues, then progressing to high-risk roles and tier-0 systems. Throughout, instrument everything: measure adoption, track fallbacks, and review incidents where step-up or block events occurred. Most organisations find that the fastest wins come from enabling platform passkeys for the broad workforce and issuing roaming keys to admins and privileged engineers. Cryptographic, username-less systems can sit in front of SSO to simplify the UX further while still meeting Cyber Essentials’ insistence on strong auth. A practical policy kit you can adapt is outlined in this CE-focused guide to replacing weak 2FA with phishing-resistant authentication.

Architecture: IdP + SSO + WWPass + device trust

A robust passwordless architecture places the IdP/SSO at the centre, with phishing-resistant authenticators at the edge, and device trust as the gatekeeper. Users unlock their device with a platform authenticator; they access SSO guarded by conditional access that demands phishing-resistant MFA; and they reach apps via federated protocols that carry user and device claims. Admins operate in a separate tier: they sign into hardened workstations, present a roaming security key or smart card, and interact with admin portals in isolated browser profiles. Cryptographic systems like WWPass can front the SSO to remove usernames and passwords entirely while still enforcing possession and user verification; that reduces phishing surfaces and makes the login state easier to reason about. The pieces are not exotic: they are the current best practice described by NCSC and implemented daily by UK organisations pursuing Cyber Essentials and Zero Trust simultaneously.

Policy baselines: enrollment, recovery, step-up rules

Codify the three policies that make or break passwordless. Enrollment must prove the link between a person and their account, preferably in person or via strong identity proofing, and must result in at least two authenticators registered (for resilience). Recovery must be phishing-resistant too; it should require an existing registered authenticator or a supervised reset with HR/IT approval, never just email or SMS. Step-up rules should require additional verification for administrative actions, high-risk transactions, or access from lower-trust contexts. Keep your policy language precise: name the methods you treat as phishing-resistant, state where weaker OTPs are allowed only as fallbacks with compensating controls, and define the process for exceptional access. This clarity both satisfies assessors and protects users from inconsistent experiences.

Privileged access: admin MFA, separate devices, break-glass

Privileged access demands a stricter model. Admins must use separate accounts and, ideally, separate devices; they must present a phishing-resistant factor for every privileged sign-in; and they should perform admin work only from managed, isolated environments. Maintain at least two break-glass accounts protected with hardware tokens, sealed operational procedures, and out-of-band storage. Test those accounts regularly but restrict their use to emergencies. Adopt the discipline that any change to conditional access, MFA registration, federation, or directory sync demands step-up authentication by more than one admin, and ensure that auditing is immutable and reviewed. This “belt and braces” approach is grounded in UK guidance and, more importantly, in hard-won lessons from incident response.

Audit readiness for UK certification

Preparing for UK certification is about setting yourself up to prove—clearly, consistently, and repeatably—that your Cyber Essentials access control is enforced in production, not just described on paper. Certification bodies assess the controls as they actually operate across your devices and cloud services, and for Cyber Essentials Plus they validate this with technical tests and sampling. The most efficient way to reach audit-ready confidence is to treat your environment as a living system: define the boundary and scope, instrument the controls, collect auditable evidence as part of normal operations, and close the loop with remediation and retesting. When you do this with passwordless, phishing-resistant authentication at its core, everything else gets easier: you can demonstrate that MFA is enforced on every in-scope cloud service, that administrative access uses separate identities with stronger factors, and that exceptions are controlled and minimised. The official Requirements for IT Infrastructure (v3.2) make these expectations explicit by requiring MFA on all cloud authentication and by mandating separate admin accounts for privileged activity; the Cyber Essentials Plus Test Specification (v3.2) explains how assessors verify scope, choose representative samples, and apply a strict pass/fail model to each test case. These two documents are the north star for audit readiness under the current “Willow” question set introduced in April 2025, and they are your authoritative baseline for planning, evidence, and remediation.

Evidence pack: MFA enforcement, user lists, config exports, logs

Audit-ready teams don’t scramble for screenshots the week of the assessment. They maintain an “evidence pack” that is generated by normal operations and refreshed on a defined cadence. At minimum, you should be able to prove four things at any time. First, that MFA is enforced for all users of all cloud services in scope, not only for administrators. The simplest way to prove this is to export the identity provider’s conditional access or authentication policy configuration, capture enforcement views from each major SaaS, and keep dated screenshots alongside machine-readable exports. The Requirements for IT Infrastructure (v3.2) state unambiguously that authentication to cloud services must always use MFA, and the IASME Knowledge Hub clarifies that all cloud services are in scope and MFA is required for all users accessing them; your evidence should line up with that wording.

Second, maintain user lists and role assignments that reflect least privilege and separate admin accounts. A clean export from your IdP that shows unique user accounts, group memberships, and admin role assignments supports multiple controls at once: it evidences unique identities, least-privilege role design, and admin separation. It also helps assessors select representative samples for testing, including normal users and administrators for each cloud service as required by the CE+ Test Specification.

Third, prepare configuration exports for secure configuration on endpoints and servers. For Windows and macOS fleets, that typically means baseline policy exports that show phishing-resistant sign-in enabled at the OS (for example, Windows Hello for Business with hardware-backed credentials), local admin restrictions, application control, and browser security. For cloud services, it means exporting or capturing policy states that disable legacy protocols, enforce modern authentication, and block password-only fallback. Because CE+ relies on sampling, being able to show standardised builds and centrally enforced policies makes it easier for an assessor to gain confidence that a small sample is representative of the whole.

Fourth, keep sign-in and change logs that demonstrate controls actually fire. Sign-in logs should show successful and blocked attempts and clearly indicate whether MFA was applied. Administrative logs should record changes to conditional access, MFA registrations, and federation; these are high-impact events that should trigger step-up verification. Although Cyber Essentials is a baseline and not a full audit standard like ISO/IEC 27001, the Plus specification’s sampling approach and strict pass/fail logic mean you benefit from having authoritative logs that corroborate your policy exports. In practice, many organisations go further by creating a small set of audit queries in their SIEM that answer predictable questions, such as “show me interactive sign-ins without MFA in the last 30 days” or “show me changes to MFA registration methods in the last 90 days.” This makes assessments smoother and helps you remediate proactively if a control weakens between quarterly reviews.

Self-assessment vs Cyber Essentials Plus: what auditors test

Cyber Essentials at the base level is a verified self-assessment against the five control themes and must be signed off by a board member. It demonstrates that you have the baseline controls in place and that you understand and manage your scope. Cyber Essentials Plus is based on the same requirements but adds an independent technical audit with sampling and hands-on tests against your in-scope devices, servers, internet-facing services, and cloud accounts. The CE+ Test Specification (v3.2) explains that assessors must verify scope, segregation of sub-sets, and sample sizes; they run vulnerability assessments on public-facing assets, authenticated scanning on sampled devices, and malware protection tests; and they must test cloud services using a representative sample of user accounts consisting of at least one normal user and one administrator per cloud service. The specification also emphasises strict success criteria: a fail on any sub-test can fail the test case and therefore the whole assessment, subject to narrow exceptions controlled by the Delivery Partner. IASME’s public guidance mirrors this, explaining that Plus gives a higher level of assurance because controls are technically verified rather than attested.

From an access control perspective, Plus assessors look for proof that user accounts are unique and legitimate, that privileged activity is performed with separate admin identities, that MFA is enforced for internet-accessible and cloud services, and that insecure defaults or legacy protocols don’t undermine the authentication path. These expectations reflect the Requirements for IT Infrastructure (v3.2), which instruct organisations to implement MFA for cloud, use separate admin accounts, and remove or disable special privileges when no longer required. If you treat these as non-negotiable and instrument them well, the Plus testing becomes a confirmation step rather than a discovery mission.

Handling externally managed and cloud services under shared responsibility

Nearly every modern estate relies on externally managed systems and cloud software, but shared responsibility does not dilute your obligations under Cyber Essentials. The Requirements for IT Infrastructure (v3.2) make it clear that when your data or services are hosted on cloud platforms, the services are still in scope; who implements a particular control may vary by service model, but the applicant is responsible for ensuring that every required control is implemented. The IASME Knowledge Hub expands on this shared responsibility model and provides plain-English guidance on securing cloud services, beginning with creating a complete inventory of cloud platforms in use and confirming that MFA is enabled for all accounts. In practice, this means federating SaaS behind your SSO where possible, enforcing your policies centrally, and obtaining contractual or attestation-based assurance from managed service providers that they apply Cyber Essentials-equivalent controls to their administrative access, including MFA for their admin accounts.

When a third-party provider manages a service on your behalf, you remain accountable for the outcomes. That is why scope definition must include contractor and MSP access, as well as any devices and identities they use to reach your organisational data and services. IASME’s sector guidance repeatedly underscores that all devices accessing organisational data and services are in scope, including those belonging to contractors and volunteers; applying this mindset to suppliers and MSPs simplifies audits and reduces blind spots.

Rollout roadmap (30/60/90 days)

A 90-day roadmap focuses on closing the biggest audit gaps first—cloud MFA enforcement and admin account separation—then rolling out passwordless, phishing-resistant methods and hardening secure configuration. A practical programme proceeds in phases and uses discover-decide-deliver loops: discover assets and identity relationships, decide on policy baselines and exceptions, deliver changes in waves with measurement and support. The outputs of each phase feed your evidence pack and prepare you for both self-assessment and Plus.

Phase 1: inventory, scope, pilot on cloud apps

Start with inventory and scope because every other decision depends on them. Use the current Requirements for IT Infrastructure to anchor your boundary of scope and enumerate all cloud services carrying organisational data. Validate that this list is complete by cross-checking finance records, browser history telemetry, and email discovery for SaaS sign-ups. The IASME Knowledge Hub’s cloud guidance suggests creating a list of cloud services and confirming MFA for all accounts; treat this as your first milestone and convert it into an evidence-producing task. As soon as you have your inventory, pilot phishing-resistant MFA on one or two high-impact cloud services—often Microsoft 365 or Google Workspace—because this yields immediate risk reduction and demonstrates visible progress to leadership. If you are already running an IdP and SSO, you can add phishing-resistant factors without re-architecting; if not, adopt SSO as your control centre so policies can be enforced in one place. For a low-friction path to passwordless with discoverable credentials and clear auditability, examine platform passkeys and roaming security keys in tandem with a cryptographic MFA approach that removes usernames and passwords entirely. A practical pattern is to front your SSO with WWPass Multi-Factor Authentication to eliminate shared secrets in the browser while keeping your existing identity investments intact.

During the pilot, wire in conditional access to prove you can gate access by user risk, device trust, and app sensitivity. Require phishing-resistant factors for admins, finance, HR, and engineering early adopters; block basic authentication and legacy protocols that bypass modern MFA; and capture logs that show successful step-up events. The NCSC’s guidance on recommended MFA types and its passkeys blog point you toward WWPass/WebAuthn and away from weaker factors that are susceptible to phishing and interception. This pilot should produce your first round of dated screenshots, policy exports, and log queries for the evidence pack.

Phase 2: expand to the workforce and harden secure configuration

With lessons from the pilot, expand phishing-resistant MFA to the wider workforce and lock down policy fallback. If your IdP still allows password-only or weak OTP paths, tighten the controls so that only approved, phishing-resistant methods satisfy access to cloud services. The Requirements for IT Infrastructure (v3.2) explicitly caution that SMS is not the most secure MFA and recommend stronger alternatives where available, so use this phase to reduce or eliminate SMS where passkeys or cryptographic authenticators are feasible. Pair this with secure configuration on endpoints: enforce device-bound sign-in with biometrics or PIN backed by hardware security, restrict local admin rights, and deploy application control to prevent untrusted code. Because Plus testing relies on representative samples, standardising the build and enforcing policies centrally make it easier to pass with confidence.

At this stage, move beyond “MFA is on” to “MFA is enforced and measured.” Create a standing report that shows percentage of users signed in with phishing-resistant factors in the last 30 days, new registrations per week, and any residual use of weaker factors. If a service cannot federate behind your IdP or cannot enforce MFA, record it as a formal exception with a remediation plan and a target date. Where you need a username-less, password-less experience to drive adoption while improving security, consider introducing WWPass SSO to bring cryptographic login to web and mobile apps without changing each app individually; pairing platform passkeys for day-to-day users with roaming security keys for admins gives you resilience and portability.

Phase 3: privileged accounts, reporting, and CE/CE+ assessment

Finally, separate and harden admin access. The Requirements (v3.2) require using separate accounts for administrative activities; encode this with dedicated admin identities, privileged access workstations or equivalent device tiers, and stricter conditional access for admin sign-ins. Issue roaming hardware security keys or smart cards for admins and require step-up verification for any change to MFA registration, federation, or conditional access policies. Validate that no admin identity can read email or browse the web under the admin context in day-to-day work, and generate an auditable report listing all privileged roles and their assigned users. The CE+ Test Specification expects representative sampling of cloud users including admins, so ensure at least one admin account per service is test-ready with the approved sign-in flow. At the end of this phase, run an internal validation against the self-assessment question set, then book your Plus assessment within three months so scope alignment remains valid. For detailed, CE-specific implementation insight on replacing weak 2FA with phishing-resistant methods, the walkthrough in Cyber Essentials MFA: Replace Weak 2FA with Phishing-Resistant Authentication can help translate policy into day-one changes and evidence.

Common pitfalls and how to avoid them

The fastest way to derail an otherwise solid programme is to leave gaps that are obvious to assessors. The first pitfall is weak recovery. If your recovery path allows an attacker to change a user’s registered factor using only email or SMS, you have created a back door. Tie recovery to phishing-resistant re-authentication or supervised resets and record the process in your evidence pack, including approvals and logs. The second pitfall is unenrolled users at the edge of scope—contractors, interns, or business units using unauthorised SaaS. Because all cloud services are in scope and must use MFA, shadow services or unmanaged contractor identities can cause Plus failures. Maintain your cloud inventory continuously and federate access wherever possible so your central policies apply. The third is exceptions sprawl. Treat every exception as a ticket with an owner, compensating controls, and a retirement date; resist turning temporary allowances into permanent holes. The fourth is overreliance on SMS/OTP. The NCSC’s advice is clear that while SMS is better than nothing, it is not the most secure; the guidance on recommended MFA types and passkeys points organisations toward phishing-resistant approaches such as WWPass/WebAuthn. If you must use app-based OTPs temporarily, pair them with controls that reduce social engineering, and plan a dated path to stronger factors.

A subtler pitfall is admin account drift. Even when teams create separate admin identities, people revert to convenience and perform email or browsing with admin tokens, or they add blanket exclusions so admins can sign in from unmanaged devices. The Requirements (v3.2) advise against using admin accounts for routine work and require removing special privileges when no longer needed; enforce these norms with policy, not just training. Finally, be wary of scope errors. The Plus test begins with scope verification and can include checks that sub-sets are effectively segregated; if your scoping excludes legacy systems, you must prove segregation. Addressing these pitfalls early saves rework and protects the certificate timeline.

Overreliance on SMS/OTP vs phishing-resistant MFA

It bears repeating that phishing-resistant MFA changes the game for Cyber Essentials access control. When authentication is bound to the legitimate origin and to the user’s device, adversary-in-the-middle kits cannot forward credentials or prompts to hijack sessions. The NCSC’s collection on MFA recommends WWPass for its resistance to guessing, phishing, and theft; its passkeys blog recognises that adding strong, phishing-resistant factors dramatically improves outcomes compared with password-only or weaker MFA. The Requirements (v3.2) echo this by noting that SMS is not the most secure option and recommending alternatives where available. For many organisations, the quickest route to phishing-resistant login is to combine platform passkeys for everyday users with roaming security keys for admins, then add a cryptographic, username-less front door to eliminate passwords entirely. If you are exploring how to integrate this with an existing identity estate, Passwordless SSO for Web & Mobile Apps describes a practical approach to deploying strong cryptography at the SSO tier without rewriting applications.

FAQs

Is WWPass mandatory for Cyber Essentials? No. Cyber Essentials is vendor-neutral. The scheme sets technical outcomes and testable requirements, such as enforcing MFA for all cloud services and using separate administrative accounts; it does not mandate a particular vendor or product. You can meet the requirements with WWPass/WebAuthn passkeys, security keys, smart cards, or cryptographic authentication platforms like WWPass Multi-Factor Authentication and WWPass SSO. What matters is that your chosen method is strong, phishing-resistant where possible, and enforced everywhere in scope so you pass both the self-assessment and Plus technical verification.

Do contractors and MSPs fall in scope? Yes, if they access your organisational data and services. IASME guidance states that all devices accessing organisational data and services are in scope, including personal or third-party devices used by contractors, trustees, or volunteers. In addition, the shared responsibility model requires you to ensure that controls are implemented even when providers operate parts of the stack. In practice, that means federating access for contractor identities, enforcing MFA on their accounts, and obtaining assurance that MSP admin access also uses MFA and least privilege.