What Windows security settings actually matter if you don't have a dedicated security hire?

Five: disk encryption, disabling the legacy SMBv1 file-sharing protocol, switching sign-in from password to a device-bound PIN, turning on Controlled Folder Access for ransomware protection, and requiring Network Level Authentication on Remote Desktop. Each one takes about five minutes to change and has its own command to verify it actually took effect -- because a checkbox that silently failed to apply is worse than no checkbox, since you'll report it as done when it isn't.

This matters if you're the IT admin at a company with no dedicated security hire, because a lot of cyber-insurance applications and audits now ask specifically whether these five controls are on. If you can answer "yes, and here's how I checked" to all five, you've closed most of the gap between "we have antivirus" and "we can actually pass an audit."

Here is each setting: what to change, why it matters, and the exact command that proves it worked.

Turn on disk encryption (BitLocker)

If a laptop gets stolen or a drive gets pulled out of a decommissioned machine, an unencrypted disk hands over every file on it with zero effort. BitLocker is built into Windows 10 and 11 Pro, Enterprise, and Education -- Microsoft documents this in its BitLocker device encryption guidance.

Turn it on from Settings > Privacy and Security > Device Encryption -- or, on Pro and above, the fuller Control Panel BitLocker Drive Encryption applet, which lets you choose whether the recovery key backs up to a Microsoft account, Azure AD, or a printed copy kept somewhere that isn't taped to the laptop.

One real cost before you turn this on: if the recovery key is lost and the machine ever asks for it -- a motherboard swap, a failed update, a forgotten PIN -- an encrypted drive with no saved key means the data is gone, not just inaccessible. Save that key somewhere durable before you finish this step, not after.

Turn on device encryption for the boot drive and confirm the recovery key saved to your chosen location before you close the wizard. Then verify encryption actually applied from an elevated PowerShell or Command Prompt:

manage-bde -status

You're looking for "Percentage Encrypted: 100%" and "Protection Status: Protection On." If it says "Encryption in Progress" or the number isn't climbing, it isn't protecting you yet.

Turn off SMBv1

SMBv1 is the old file-sharing protocol from the Windows XP and Server 2003 era, and it's the exact protocol the EternalBlue exploit used to spread WannaCry and NotPetya across networks in 2017 -- Microsoft's own SMBv1 deprecation advisory documents this as the reason they now recommend removing it entirely, not just disabling client access to it. Most current business software doesn't need it. Old network printers and ancient NAS boxes sometimes still do -- check before you flip this on a whole fleet.

Turn it off from Control Panel > Programs > Turn Windows Features On or Off -- uncheck SMB 1.0/CIFS File Sharing Support, all three sub-items, and reboot.

After reboot, verify with PowerShell:

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

The State field should read "Disabled." If it still reads "Enabled," the uninstall didn't take and you need to run it again, this time from an elevated PowerShell session:

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Stop using a typed password as the primary sign-in

A PIN set up through Windows Hello is tied to that specific device's Trusted Platform Module -- it's not a secret that can be phished, replayed on another machine, or pulled from a password-dump breach somewhere else, because it never leaves the device. This is documented in Microsoft's Windows Hello technical overview: the PIN authenticates against local hardware, not a server-side password hash.

Set this up from Settings > Accounts > Sign-in Options. Add a PIN, and where the hardware supports it, add Windows Hello face or fingerprint on top of it.

One thing to know: the PIN is device-specific, so it does not replace the account password everywhere -- you may still need that password on other machines or for certain recovery scenarios, so don't delete or forget it.

After setting the PIN, sign out and sign back in using only the PIN to confirm it's actually the default. Then check Settings > Accounts > Sign-in Options again -- Windows Hello PIN should show "Set up." If your organization uses Group Policy, run this from an elevated prompt:

gpresult /r

This shows whether a sign-in policy is actually being applied to that machine, not just configured somewhere upstream and never delivered.

Add MFA -- the PIN protects the device, not the accounts it reaches

A device-bound PIN solves sign-in to that one machine. It does nothing for the accounts that machine then reaches -- email, banking, your cloud admin console. Those accounts are still only as strong as a password, and passwords get phished, reused, and leaked in breaches that have nothing to do with your device. The PIN and MFA solve two different problems: one is "is this the right device," the other is "is this the right person, even if they have the password."

Turn on multi-factor authentication on every account that offers it, starting with email, then anything with financial, admin, or customer data behind it. An authenticator app or hardware key is stronger than a text-message code, but a text-message code still beats a password alone.

Do this now: turn on MFA for your most important account today, then sign out and back in to confirm it actually prompts for the second factor -- a setting that doesn't prompt on the next sign-in didn't save correctly.

One real cost: lose the second factor without saved backup codes and you can lock yourself out of your own account. Save the backup codes the setup flow gives you before you close that screen -- the same discipline as the BitLocker recovery key above.

Use a password manager -- you still have passwords, the goal is not remembering them

MFA is a second factor added to a password, not a replacement for one, and plenty of accounts don't offer MFA at all. The actual goal is that you never have to remember a password, so every account can carry a long, unique credential instead of a memorable, reused one. A password manager generates and stores those credentials so a breach on one site doesn't hand over the password to every other site you used it on.

We recommend Keeper Security for this -- full disclosure, it's a product we resell.

One real cost, and it's an important one: a password manager becomes a single high-value target, because compromising the vault compromises everything in it. Its master password and its own MFA matter more than any other credential you own.

Do this now: install a password manager, turn on MFA for the vault account before adding a single stored password, then migrate email, banking, and admin consoles to generated unique passwords first.

Turn on Controlled Folder Access (ransomware protection)

Controlled Folder Access is Microsoft Defender's ransomware protection feature -- it locks down which applications are allowed to write to your Documents, Desktop, Pictures, and other protected folders. An unrecognized process trying to encrypt your files gets blocked and you get a notification. This is documented in Microsoft Defender's Controlled Folder Access guidance as specifically targeting ransomware-style mass file modification, not general malware scanning -- that's a separate, always-on layer underneath it.

Turn it on from Windows Security > Virus and Threat Protection > Ransomware Protection, then flip Controlled Folder Access to On. Add any line-of-business apps that legitimately need to write to those folders so you're not fighting false blocks all week.

Verify with PowerShell:

Get-MpPreference

Check the EnableControlledFolderAccess value. A 1 means it's on. A 0 means the toggle didn't stick, which happens more often than you'd think on machines managed by more than one policy source.

Require Network Level Authentication on Remote Desktop

If Remote Desktop is enabled on this machine at all, require Network Level Authentication (NLA) before a connection is even allowed to reach the sign-in screen. NLA forces the user to authenticate before the full RDP session negotiates, which closes off a class of pre-authentication attacks against the RDP service itself -- documented in Microsoft's Remote Desktop security guidance as the primary reason NLA is the recommended default.

The real cost here: any client that does not support NLA -- an old RDP client version, some third-party or embedded remote-access tools, older non-Windows RDP clients -- will be refused a connection outright once this is on, with no fallback. Before you flip it, check what actually connects to this machine today. If you don't know, leave it off until you do, or test on one machine first and confirm every regular connection still works before rolling it out further.

Turn it on from System Properties > Remote tab, and check "Allow connections only from computers running Remote Desktop with Network Level Authentication." While you're there, pair it with an account lockout policy so repeated failed logins actually lock the account -- Local Security Policy > Account Policies > Account Lockout Policy, set a lockout threshold instead of leaving it at the Windows default of no lockout at all.

Verify NLA with PowerShell:

Get-WmiObject -class Win32_TSGeneralSetting -Namespace root\cimv2\terminalservices

Check that UserAuthenticationRequired equals 1. Verify lockout policy with:

net accounts

The "Lockout threshold" line should show a number, not 0.

The next one is not a setting: a backup you have actually restored

Five settings is the floor, not the finish. If you do one more thing after this list, make it backup -- specifically, a backup you have restored from at least once.

Controlled Folder Access above stops ransomware from encrypting your files. Backup is what saves you when something gets through anyway, and something eventually does. Ransomware protection without a tested restore is half a control: the lock, and no spare key.

Most businesses have something running. What almost nobody has is a restore anyone has actually performed, so nobody knows the backup produces a usable file until the morning they need one. A backup you have never restored is a hope with a scheduled task attached.

Check what versions exist:

wbadmin get versions

Then restore one real file -- a document you actually use, not one you made for the test -- and open it. If the restore errors, the file opens empty, or nobody knows the credentials to run it, you learned that today instead of during an incident.

Same verify-it-took-effect habit as all five settings above, which is why backup is the next piece rather than a separate topic.

The habit that outlasts any single Windows version

None of this required a security hire, a new budget line, or a vendor call. It required knowing which five toggles matter and confirming each one actually took effect instead of trusting that clicking a checkbox was the same as being protected.

That's the real skill, and it outlasts any specific version of Windows. Settings move around between releases -- the toggle location changes, the menu gets renamed. The verify-it-took-effect habit doesn't change. Every security setting you ever configure, on any system, gets the same two-step treatment: turn it on, then prove it with a command that doesn't lie to you the way a UI toggle sometimes does.

If your team is trying to get to a defensible security posture without hiring a dedicated security person, this is the kind of work that turns into a repeatable checklist with evidence attached to every line -- not a one-time pass you hope holds up at audit time.