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. It also simplifies compliance evidence: proving a login flow enforces strong, origin-bound cryptography is far easier than proving every 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. 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.

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 organisations to define scope clearly, implement the controls consistently within that scope, and provide evidence that each control is operating effectively.

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.

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.

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 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.

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.

Least privilege is not a one-time configuration; it is a governance loop tied to joiner-mover-leaver events and periodic recertification. The NCSC cloud principles underscore that granular access and least privilege reduce the blast radius of compromise.

Joiner-Mover-Leaver: onboarding, changes, revocation

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.

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. 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. 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, and demand step-up for high-impact actions such as changing MFA methods or modifying conditional access itself. Maintain at least two break-glass accounts protected with hardware tokens and out-of-band storage, tested regularly but restricted to emergencies.

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.

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. 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

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.

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. The NCSC's phishing guidance and its passkeys blog 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.

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

Many organisations deploy both: platform passkeys for daily use, with a roaming key as a backup and for privileged sessions.

Secure configuration and device trust for OS login

Passwordless falls over if devices are misconfigured. Harden your endpoints so that only approved authenticators can sign in and 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 requiring a compatible TPM. On macOS and mobile, ensure passkeys are enabled, screen-lock is mandatory, and biometric unlock requires a passcode fallback.

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 risky networks and devices. 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.

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; 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. 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.

Cloud services: enforcing MFA for all cloud access

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 it 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, and review sign-in logs for legacy protocols and conditional-access failures.

Rollout roadmap (30/60/90 days)

A practical programme runs three tracks in parallel: architecture (IdP, SSO, phishing-resistant authenticators, conditional access, admin-tier model), enrolment and recovery (binding authenticators to users with high integrity, codifying recovery so it can't be social-engineered), and migration (moving users and apps in waves, lowest-risk first). Instrument everything throughout: measure adoption, track fallbacks, and review step-up or block events.

A 90-day roadmap operationalises those tracks, closing the biggest audit gaps first.

Phase 1: inventory, scope, pilot on cloud apps

Start with inventory and scope because every other decision depends on them. Enumerate all cloud services carrying organisational data, and validate the list 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. 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. The NCSC's guidance on recommended MFA types points you toward WWPass/WebAuthn and away from weaker factors susceptible to phishing.

Phase 2: expand to the workforce and harden secure configuration

Expand phishing-resistant MFA to the wider workforce and lock down policy fallback. The Requirements for IT Infrastructure (v3.2) explicitly caution that SMS is not the most secure MFA, 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, restrict local admin rights, and deploy application control.

Move beyond "MFA is on" to "MFA is enforced and measured." Create a standing report showing percentage of users signed in with phishing-resistant factors, new registrations per week, and any residual use of weaker factors. If a service cannot federate or enforce MFA, record it as a formal exception with a remediation plan and target date. Where you need a username-less, password-less experience to drive adoption, consider introducing WWPass SSO to bring cryptographic login to web and mobile apps without changing each app individually.

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

Separate and harden admin access: 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. Run an internal validation against the self-assessment question set, then book your Plus assessment within three months so scope alignment remains valid.

Audit readiness for UK certification

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.

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.

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" generated by normal operations and refreshed on a defined cadence, proving four things at any time:

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.

Because CE+ relies on sampling, standardised builds and centrally enforced policies make it easier for an assessor to trust that a small sample represents the whole. A few standing SIEM queries, such as "sign-ins without MFA in the last 30 days", let you remediate proactively rather than scrambling before the review.

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, signed off by a board member. Cyber Essentials Plus 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) has assessors verify scope, run vulnerability and authenticated scans on sampled devices, and test cloud services with at least one normal user and one administrator per service. A fail on any sub-test can fail the whole test case, subject to narrow exceptions controlled by the Delivery Partner.

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. 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

Shared responsibility does not dilute your obligations under Cyber Essentials. 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 you remain responsible for ensuring every required control is implemented. The IASME Knowledge Hub recommends starting with a complete inventory of cloud platforms in use and confirming MFA is enabled for all accounts, then obtaining assurance that managed service providers apply equivalent controls to their own admin access. (See the FAQ below for how this extends to contractors and MSPs specifically.)

Common pitfalls and how to avoid them

• 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.

• Unenrolled users at the edge of scope. Contractors, interns, or business units using unauthorised SaaS. Because all cloud services are in scope, shadow services or unmanaged contractor identities can cause Plus failures. Maintain your cloud inventory continuously and federate access wherever possible.

• Exceptions sprawl. Treat every exception as a ticket with an owner, compensating controls, and a retirement date; resist turning temporary allowances into permanent holes.

• Overreliance on SMS/OTP. The NCSC's advice is clear that while SMS is better than nothing, it is not the most secure. If you must use app-based OTPs temporarily, pair them with controls that reduce social engineering, and plan a dated path to stronger factors.

• Admin account drift. Even when teams create separate admin identities, people revert to convenience and perform email or browsing with admin tokens, or add blanket exclusions so admins can sign in from unmanaged devices. Enforce separation with policy, not just training.

• 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.

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.

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. The shared responsibility model requires you to ensure controls are implemented even when providers operate parts of the stack, meaning federating contractor access, enforcing MFA on their accounts, and obtaining assurance that MSP admin access also uses MFA and least privilege.