Firewalls get the budget, but three humble Group Policies stop more real office incidents than anything else: a password policy people can live with, a screen that locks itself, and users who are not admins on their own PCs.
Every office security story has the same three villains. A password like Office@123 that the whole department knows. A PC left unlocked and signed in while its owner is at lunch. And a user with full admin rights who double-clicks one wrong attachment. Three Group Policies answer all three, and none of them needs a single rupee of new hardware. This page sets each one honestly - including the parts admins usually learn from a bad day: why a too-strict password policy makes passwords weaker, and why removing local admin rights is not the same as locking IT out.
A modern office baseline: long passwords, no forced monthly change, and a lockout that slows guessing without locking out the whole office by accident. Example values shown.
The old recipe - 8 characters, change every 30 days - produced a predictable result: Office@123 in January and Office@124 in February, written on a sticky note under the keyboard. Microsoft's own current baseline guidance dropped the forced expiry for exactly this reason.
What works: minimum length 12 or more, complexity on, history of 12 so the same password cannot rotate back immediately, and no routine expiry unless you suspect a compromise. Passphrases like chai-biscuit-morning are long, strong and actually remembered - which means they never end up on the sticky note.
The password policy's partner lives one node below it: Account Policies - Account Lockout Policy. Ten invalid attempts, then the account locks for 15 minutes.
Be honest about the trade-off. A threshold of 3 sounds safer, but in a real office it means one colleague who forgot a changed password - or one mischievous person typing wrong passwords at someone else's unattended login screen - locks accounts all day. Lockout is also a denial-of-service lever against your own users, so pick numbers that stop a guessing script (thousands of tries) without punishing a human (a handful of typos). Ten and fifteen does that.
Set it under User Configuration - Administrative Templates - Control Panel - Personalization: screen saver on, timeout 600 seconds, password-protected. The machine-side equivalent is Interactive logon: Machine inactivity limit.
The office story needs no imagining: the accounts manager leaves for a meeting, the PC stays signed in to the accounting software, and the salary sheet is one curious click away. Multiply that by every desk in the building. Ten minutes of inactivity and the screen simply locks - the owner types a password on return and loses five seconds; the office loses an entire class of incident. If a presentation PC genuinely needs a longer delay, that is a separate GPO for that OU, not a reason to drop the rule for everyone.
The third policy is the one users notice: taking their account out of the local Administrators group. Use Preferences - Control Panel Settings - Local Users and Groups to rebuild that group on every PC: the IT support group stays, stray personal accounts go.
Why it matters more than the other two combined: almost every serious infection begins with code running as the signed-in user. If that user is an admin, the malware is an admin - it can disable antivirus, create accounts and move across the network. If the user is standard, the same double-click usually dies at a UAC prompt the user cannot approve. Nothing else on this page shrinks the blast radius this much.
The obvious objection - then how does IT fix anything? - has a proper answer: Windows LAPS. Every PC gets its own local administrator password, automatically randomised, rotated on a schedule, and stored against the computer account in Active Directory where only IT can read it.
That kills the other classic sin: one shared local admin password across the whole office, known by every technician who ever worked there. With LAPS, a helpdesk engineer reads the password for that one PC, uses it, and it changes itself afterwards. Set up LAPS and test a retrieval before you remove anyone's admin rights - the order matters.
Week one: password policy and lockout. Week two: screen lock, announced in advance. Week three onwards: local admin removal, department by department, with LAPS already proven.
And keep a written exception list - the design PC that needs a plugin installed daily, the lab machine with odd hardware. Exceptions owned openly stay small; exceptions refused become shadow IT. These three policies are the security trio of the top-10 list - the deep mechanics of creating and linking them live in the full GPO tutorial on this channel.
The password, lock and admin settings are all configured live in the Top 10 GPO video - see the exact values before you set your own.
▶️ Watch Full VideoIt stops them installing software that needs admin rights, which is most system-level software and most malware. Per-user apps that install inside the profile (some browsers and chat tools) can still appear - that is what the software-control policy (AppLocker or SRP) in the top-10 list is for. The two policies work as a pair.
Put the presentation or director PCs in their own OU with a longer timeout - 30 minutes, say - instead of disabling the lock. The risk window shrinks, the rule survives, and nobody has to win an argument about whether security applies to everyone. A written, owned exception beats a quietly dead policy.
Because humans mistype. At 3 attempts, one forgotten password change locks accounts repeatedly all morning, and a prankster can lock out the whole office from one login screen. Ten attempts still stops automated guessing completely - a script needs thousands of tries, not nine.