Secure configuration

Secure configuration means setting devices and services up so they only do what they need to, with the weak defaults removed. Requirements v3.3 asks you to remove unnecessary accounts and software, change default or guessable passwords, disable auto-run, make users sign in before reaching data, and protect device unlocking against guessing.

Why defaults are a problem

Out of the box, computers, network devices and cloud services often come with an admin account that has a publicly known password or no MFA, extra user accounts nobody needs, and software or services you will never use. Each of these gives an attacker an easier way in. The control applies to servers, desktops, laptops, tablets, mobile phones, thin clients, and IaaS, PaaS and SaaS services.

The requirements, in plain English

Version 3.3 says you must actively manage your devices and regularly:

1. Remove or disable unnecessary user accounts. Guest accounts, default accounts and admin accounts that will not be used should go.
2. Change any default or guessable account password. Use a unique password that meets the password rules. See passwords and passkeys.
3. Remove or disable unnecessary software. This includes applications, system utilities and network services. Trial software, games, old browser toolbars, unused remote access tools and services such as file sharing you do not use all count.
4. Disable auto-run. Turn off any feature that runs files without the user's say-so, for example when media is inserted or a file is downloaded. On Windows that means AutoPlay set to take no action, ideally enforced by policy.
5. Make users authenticate first. Nobody should reach organisational data or services without signing in. Remove anonymous and guest access to file shares, intranets and cloud folders.
6. Lock devices. Users who are physically present must unlock the device before using it.

Device unlocking

Where a device needs someone physically present to use it, such as signing in to a laptop or unlocking a phone, a credential must be in place first. That can be a biometric, a password or a PIN.

Protect against guessing. Where the device lets you configure it, use one of:

• throttling, where the wait between attempts grows after each failure, allowing no more than 10 guesses in 5 minutes, or
• lockout after no more than 10 failed attempts.

If the vendor does not let you change this, the vendor's default setting is accepted. Phones from the main vendors already slow down or lock after repeated wrong codes.

Credential length. If the PIN or password is used only to unlock the device, it must be at least 6 characters. A 4-digit phone passcode does not meet this. If the same credential is also used to sign in to accounts or services, as a Windows or Mac login password often is, the full password rules in user access control apply instead.

Biometrics such as fingerprint or face unlock are acceptable. Most devices fall back to a PIN or password when the biometric fails, and that fallback is still a way in, so set it to meet the length rule too.

Common problems

• Four-digit passcodes on phones or tablets.
• A local guest account still enabled on Windows PCs, or a default admin account on a NAS or printer server.
• A router or cloud console still using its original password.
• Old software installed "just in case", which then also misses updates.
• Shared folders or cloud links open to anyone with the address.

What to do

1. Run a software inventory on each device type and uninstall what is not needed.
2. Review accounts on each device and cloud service. Disable guest and unused accounts.
3. Change every default password on devices, consoles and cloud tenants.
4. Turn off AutoPlay on Windows computers and servers by policy.
5. Set minimum 6-character unlock PINs and lockout or throttling through Intune, your MDM or local policy.
6. Check file shares and cloud sharing settings for anonymous access.

The readiness checker asks about each of these and explains what counts as compliant.