Cyber Essentials 5: accounts, administrators and cloud MFA

Build the account population

Start with your cloud and device registers, then export users and privileged roles from every relevant service. Include local accounts, direct cloud logins, guests, supplier access and accounts used for integrations. An identity-provider export does not necessarily contain accounts created directly in a SaaS product.

For each account record its owner, purpose, privileges, approval, authentication method and last review. Investigate unknown owners before making declarations. Do not disable a service account blindly: identify its dependencies and arrange a controlled replacement or removal. A broken payroll integration is not a useful way to discover what an account did.

The user-access requirements include approval for account creation, unique credentials, removal of unnecessary accounts and privileges, and separate accounts for administrative activity. Ordinary work should use ordinary privileges. Check the local administrator group as well as cloud roles; a user can have a modest cloud role and still administer their laptop.

Apply the 2026 cloud rule

Version 3.3 requires MFA for cloud-service authentication. More generally, MFA must be implemented where available under the scheme's user-access requirements. Do not assume “MFA offered by the vendor” means your tenant enforces it. Test sign-in with a representative ordinary account and an administrator, including direct access that might bypass your normal SSO route.

At fictional Merefield, Microsoft 365 uses MFA but the accounting service has two direct logins. The cloud inventory exposes the gap. The owner confirms the supported enforcement method, enrols the users, verifies sign-in and removes any obsolete bypass. A statement about Microsoft 365 would not have answered the question for accounting.

Identify legacy authentication, recovery routes and exceptional accounts. Ask the assessor how the current requirement applies to any non-interactive identity or unusual authentication flow; do not invent a broad service-account exemption. Use vendor documentation to establish what the mechanism actually does and retain the clarification with the evidence.

Separate administration from everyday use

Give people who administer systems a distinct administrative identity and keep email, routine browsing and ordinary work on their normal account. Time-limited privilege elevation can reduce exposure but does not automatically satisfy the separate-account requirement. Confirm that the underlying account arrangement matches the scheme.

Test a routine activity on the ordinary account and an approved administration task on the privileged account. Look for unnoticed access inherited through groups. Record the effective role, not only the role you intended to assign. Remove dormant supplier administrators and agree how new access is approved and withdrawn.

Administrative recovery also needs protection. Keep recovery credentials out of the assessment pack and test the authorised recovery procedure without disabling the only working administrator. The control has to survive staff absence or a lost factor; a procedure stored exclusively behind the failed sign-in route may be unusable.

Match passwords to the actual requirement

For the password element of MFA, v3.3 specifies a minimum of eight characters without maximum-length restrictions. For password-only authentication, the requirements offer defined approaches to password quality and brute-force protection, including a minimum of 12 characters without a maximum-length restriction, or a minimum of eight without a maximum-length restriction combined with automatic blocking of common passwords. Password-only accounts also need the specified throttling or lockout protection: no more than ten guesses in five minutes, or lockout after no more than ten unsuccessful attempts. Read the exact options in the requirements before describing a system as compliant.

Do not confuse a six-character device-only unlock PIN with an account password. Do not add arbitrary monthly password changes and claim CE requires them. Use a password manager where appropriate and protect its own access and recovery. Passkeys and other passwordless methods need to be understood in terms of the factors actually used; a marketing label alone is not evidence of MFA.

Where a SaaS vendor's constraints appear incompatible with the scheme, raise that before submission. Document the product and configuration, seek the certification body's interpretation, and plan a supported remedy. An internal exception approval cannot waive a mandatory certification requirement.

Test a leaver across service boundaries

These checks are an operational exercise, not a claim that every listed action is a separately worded CE question. Choose a completed leaver and trace it across the inventory. If you have had no leavers, run a controlled test with a non-production identity and label the result as a test. Never fabricate historical evidence.

Leave with a defensible access record

Ask a colleague to choose a cloud service from the register. Demonstrate an ordinary sign-in, the relevant MFA enforcement and the separate administration route without revealing secrets. Then identify the owner and approval for one privileged account. If you cannot do that, keep the item open.

Your outcome is an account register, tested authentication paths and a list of corrected or unresolved exceptions. Part 6 brings malware protection and estate-wide evidence together before the self-assessment is signed.

Check your understanding