Secure Configuration for Cyber Essentials: The Controls Assessors Expect to See

Secure Configuration for Cyber Essentials: The Controls Assessors Expect to See

Secure configuration is the widest Cyber Essentials control area. It covers operating systems, applications, cloud services, and mobile devices, and every element has its own set of default settings that need attention. When I review a submission, this is where applicants most often have the right intent but miss specifics the scheme wants to see.

This guide walks through what the rule requires, which settings assessors explicitly check, and how to describe your posture in the questionnaire so it passes on the first submission.

What the rule says

The NCSC requirement is that every in-scope device, operating system, application, and cloud service is configured to reduce vulnerabilities and limit what the device can do to the minimum needed for its purpose. In the question set this breaks down into four concrete asks:

What catches applicants out is the scope. Secure configuration applies to every device type — workstations, servers, phones, tablets, routers, firewalls, printers that process organisational data, and every cloud service in scope. A single unmanaged IoT device with factory defaults can fail this section.

What counts as a "default password"?

Any password that ships from the vendor or any factory-set credential on a device counts. This includes:

All of these count. "We only changed the passwords on the things that looked important" is not a passing posture. Every device with an administrative credential has had its default changed.

The practical test: if you handed the device to a penetration tester with only its make and model, could they log in using vendor-published defaults? If yes, that password has not been changed.

What about auto-run and auto-play?

The scheme asks specifically about auto-run and auto-play because historically these features were a common vector for malware spreading via USB drives. Modern operating systems disable them by default, but the question set still asks explicitly.

For Windows, auto-run and auto-play should be disabled via Group Policy or Intune at the tenant level — not left to user preference. The setting is "Turn off Autoplay" under Computer Configuration → Administrative Templates → Windows Components → AutoPlay Policies. The correct value is "Enabled" with "Turn off Autoplay on" set to "All drives".

For macOS, there is no equivalent auto-run feature that needs disabling, but the question set's intent — that removable media cannot automatically execute code — is met by the default macOS configuration. If you have installed any software that adds auto-mount behaviour, review it.

Removing unused software and accounts

The question set asks whether you have removed or disabled unnecessary software, user accounts, and services. This is where two specific traps catch applicants.

Trap 1: Pre-installed vendor software. New Windows laptops ship with trial software, hardware utilities, and manufacturer apps. Most of it is never used and some of it has a history of vulnerabilities (Dell SupportAssist and Lenovo utilities have both had critical CVEs). A standard Cyber Essentials posture is to use the Windows OOBE enterprise deployment process or to run a debloat script after imaging. "We leave the Lenovo Vantage on because users sometimes want it" is an answer that triggers assessor follow-up.

Trap 2: Dormant user accounts. When someone leaves the organisation, their accounts need to be disabled promptly — not "next quarter", not "when we get around to it". The scheme does not specify a number of days in the question set but in practice assessors expect the answer to be "within one working day of departure" or "as part of a documented leaver process run weekly". Accounts belonging to contractors, interns, or former service accounts that are still enabled will fail this section during a Plus audit.

For cloud services, the same rule applies. Every in-scope SaaS tool should have an offboarding process that disables leavers promptly. A common failure is that the organisation has Microsoft 365 offboarding in hand but leaves accounts active on secondary tools (the CRM, the accounting platform, the HR system).

Users cannot undermine security settings

This requirement is often mis-interpreted as "users should not have local admin rights". That is part of it, but the actual requirement is broader: the configuration of the device must be such that a standard user cannot, through normal day-to-day activity, turn off security controls.

The specific things that need to hold:

The standard mechanism for this is a combination of MDM policies (Intune, Jamf, Kandji) and local admin rights restrictions. Users operate as standard users; administrators operate with separate admin accounts for administrative tasks. Giving every user local admin "because they're technical" is an automatic fail.

Cloud service secure configuration

The v3.3 question set is explicit about cloud services. Secure configuration applies to Microsoft 365, Google Workspace, AWS, Azure, Salesforce, and every other SaaS or IaaS service in scope.

The specific configurations assessors expect:

Identity and access. SSO integration where available. Users assigned least-privilege roles. Admin accounts separate from daily-use accounts. No shared credentials.

Defaults hardened. "Security Defaults" enabled on Microsoft 365 tenants that do not have Conditional Access licensing. Equivalent baseline on Google Workspace. Anonymous external sharing disabled by default on OneDrive, SharePoint, and Google Drive.

Data residency. For UK organisations, cloud services configured to store data in UK or EEA regions where that option exists. Not strictly required by Cyber Essentials but flagged during assessment if data residency choices look casual.

Admin trails. Audit logging enabled and retained for a reasonable period. Not an explicit CE requirement but an implicit expectation when the assessor probes your incident response posture.

API and app permissions. Third-party app consent restricted — users cannot grant arbitrary OAuth scopes to unknown apps. This catches submissions during the technical audit because a casual consent model allows malicious OAuth apps to access organisational data.

What assessors check in the questionnaire

For secure configuration, the passing answers tend to include specific artefacts:

Vague answers get feedback. "We keep things secure" is not an answer. "We use Intune baseline policies applied to all Windows 11 devices, with the following specific controls enforced…" is an answer.

The five secure configuration failures I see most often

1. Local admin rights for all users. The single biggest failure. "Our team are all technical so they need local admin" is not a valid position under v3.3.

2. Dormant accounts. Leavers' accounts still active, often with access to cloud services the IT team has forgotten about.

3. Default passwords on secondary network devices. Managed switch, printer web UI, or IP camera still at factory defaults.

4. User-disableable security controls. Windows Firewall can be toggled by any user. Anti-malware status can be changed. Screen lock can be removed.

5. Unrestricted OAuth consent. Users can grant third-party apps full access to organisational Microsoft 365 data without admin approval.

Each of these is fixable in an afternoon with the right tools — Intune baseline policies, a leaver reconciliation, a network device audit, tightened OAuth consent settings. Fix them before submitting.

Pre-submission secure configuration checklist

1. Local admin rights. Do any standard users have local admin on their work device? If yes, fix before submitting or document why the exception is in place.

2. Leaver reconciliation. When was the last time you reconciled HR records against active accounts across every in-scope service? If the answer is "not recently", run it now.

3. Default credential audit. Can you list every network device, printer, and IoT device with an admin interface, and confirm factory defaults were changed?

4. Configuration enforcement tool. Can you name the tool (Intune, Jamf, Kandji, etc.) and the specific policies that enforce your baseline?

5. OAuth / API consent. On Microsoft 365, is third-party app consent restricted to admin approval? On Google Workspace, is the app access control configured?

6. Pre-installed software. Have you removed vendor bloatware from laptops during imaging?

Six checks. Each takes fifteen minutes. Each addresses a specific question the assessor will ask.

Bottom line

Secure configuration is not a single question; it is a spread of questions across every device class you run. The applicants who pass first time are the ones who treat it as a list of specific settings rather than a vague "we're secure" assertion. Pick a configuration enforcement tool, document your baseline, hunt down the unglamorous corners (the printer, the IoT camera, the leavers' accounts), and submit with specifics rather than generalities.

Check your readiness | View pricing | Talk to an assessor