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 under v3.3 (effective 27 April 2026), which settings assessors explicitly check, and how to describe your posture in the questionnaire so it passes on the first submission.

Use the current NCSC text rather than attributing every local hardening choice to a version change. Page 16 specifies at least six characters for device-only passwords or PINs, technical quality controls and guess protection. Credentials also used for authentication need the full password rules.

There is no universal fifteen-minute lock timer or mandatory Defender tamper-protection change in that text. Cloud-delivered protection, shorter lock timers and managed baselines can be useful hardening. See the device unlock guide for the actual credential rules.

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. The core requirements include:

• Remove or disable unused software, user accounts, and services
• Change all default passwords on devices, software, and services
• Disable auto-run and auto-play features
• Authenticate users before access to organisational data or services
• Apply appropriate device locking, technical credential quality and guessing protection

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.

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

• Router admin accounts (`admin/admin`, `admin/password`)
• Printer web interfaces (often no password at all, or `admin/0000`)
• Managed switch management accounts (Cisco `cisco/cisco`, HP `admin/`)
• IP cameras (very often unchanged from factory)
• NAS devices (`admin/admin` on older Synology, QNAP, Netgear ReadyNAS)
• VoIP phones and IP-PBX admin interfaces
• UPS monitoring interfaces
• Hypervisor management consoles (VMware `root` with shipped password)
• Cloud service admin accounts created during provisioning

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.

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.

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. Review whether each application or utility is necessary for the device's role and keep retained software supported and patched. Enterprise imaging or controlled removal can help; a vendor utility or trialware label alone is not an automatic failure. Avoid indiscriminate debloat scripts that remove software the organisation needs.

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". Remove or disable accounts when no longer required. The scheme does not prescribe a universal one-day deadline or weekly leaver batch. Set a process that achieves the requirement; a local SLA is operational policy. 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).

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 software firewall must be enabled and cannot be disabled by the user
• The chosen qualifying malware protection must remain effective; for an anti-malware implementation, prevent users disabling it
• Screen lock and password requirements cannot be removed by the user
• Patching cannot be indefinitely deferred by the user
• The user cannot install arbitrary software without approval

MDM policies (Intune, Jamf, Kandji) and local admin restrictions are useful implementation options, not compulsory products. 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.

Apply the relevant controls to each in-scope cloud service according to your responsibility boundary. Use approved account creation, unique credentials, least privilege, separate administrative accounts, MFA for cloud authentication and removal of unnecessary accounts or access.

SSO and central identity can make those controls easier to manage, but are not mandatory. Select supported Security Defaults or Conditional Access settings and test effective MFA rather than treating a named baseline as an automatic pass.

Additional hardening: external-sharing restrictions, data residency choices, audit-log retention and OAuth app consent deserve deliberate decisions. They are not universal Cyber Essentials assessor pass tests. Other legal, contractual or assurance obligations may require them separately.

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

• Build standards. "All Windows devices are imaged from a standard baseline build based on CIS Benchmarks / Microsoft Security Baseline, applied via Intune policies."
• Leaver process. "Accounts are disabled within one working day of HR notification. We run a monthly reconciliation between HR and Entra ID."
• Configuration enforcement. "Users do not have local admin rights. Admin actions are performed by named IT staff using separate admin accounts."
• Default credential audit. "All network devices, managed switches, printers, and IoT devices had factory credentials changed during provisioning; we run a quarterly audit via [tool]."
• Auto-run. "Auto-run and auto-play are disabled via Intune policy across all Windows devices."

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.

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. Missing locking or credential protection. Applicable device locking, credential-quality or guess-protection settings are absent. OAuth consent restrictions are separately recommended hardening.

Investigate the actual gaps before submitting. Remediation time depends on the estate and controls; applying a named baseline does not guarantee a fix.

1. Local admin rights. Do any standard users have local admin on their work device? Use a separate account for administrative activities; ordinary email and browsing must not use administrative privileges. A documented daily-admin exception does not replace that separation.

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. Effective configuration. Can you show the actual native or managed settings implementing your baseline? A particular management product is not compulsory.

5. Device credentials. Are applicable locking, credential-quality and guess-protection controls effective, including full password rules where unlock credentials also authenticate? Review OAuth consent separately as hardening.

6. Necessary software. Have unnecessary applications and services been removed or disabled, with retained software supported and patched?

These checks support preparation. The work and evidence depend on your actual estate, so no universal fifteen-minute completion is promised.

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