Decide the Tier, Not the Exception
Hardening stalls when it's one setting for everyone. Tier it by user group, start from a benchmark, and decide the trade-offs once per group instead of once per request.
by Phillip Büchler
Not that long ago, removing local admin rights was the project nobody wanted to start. We’d have to package every tool anyone had ever installed, the argument went, and the endpoint team would drown in configuration sets.
Today it’s standard, and looking back, two things did most of the work. Auto-updates took the pressure off packaging. And users minded far less than IT had assumed, with EPM covering most of the rest.
That second point has stayed with me, because I think we’re repeating the mistake with hardening.
Why hardening stalls
In Patch Less I argued for fewer apps and faster patching. That still leaves the days when you’re late, and with exploitation often starting before a patch exists, those days will come. So the other half of the job is limiting what a late patch can cost you.
The tools for that have been in Windows and Microsoft 365 for years. Attack surface reduction rules, App Control for Business, restrictive Office macro settings, and lately Administrator protection. In many estates I see them in audit mode, switched off after the first complaint, or never configured at all. Full hardening of Office, for example, I’ve rarely seen, because nobody has a reliable inventory of old files and macros to judge the impact.
Most of the pushback comes from users and their management, not from IT, and a lot of it is fair. A developer who can’t run their tools isn’t being difficult, and neither is the finance team whose month-end macro just stopped working. All the headlines about vulnerabilities have raised awareness, sure. It stays abstract until a measure lands on your own desk.
The usual answer is one configuration for everybody, set low enough that nobody complains, and that’s where I think it goes wrong. What a software developer can live with is far too loose for the people who approve payments, while the payment team’s settings would stop the developer cold. Tiering by user group gets you out of that bind.
Four groups, four trade-offs
Most organisations can start with four user groups. Call them what you like, as long as each group gets the strictest setting it can live with and the trade-off is written down.
| User group | Typical risk | Fitting controls | Justified objection | What you accept |
|---|---|---|---|---|
| Standard office users | Phishing, malicious attachments, drive-by downloads | No local admin, EPM for the few elevations they need, ASR rules in block mode, macros from the internet blocked | “My old Excel tool doesn’t work anymore” | A short list of exceptions, handled through trusted locations or signed macros |
| Developers and power users | Broad tool sets, scripts, package managers, local admin habits | EPM with a wider rule set, Administrator protection where admin rights stay, ASR rules with exclusions for their tools | “I need Docker, WSL and my own tools to do my job” | More freedom on the device, in return for more monitoring |
| Privileged admins | Their credentials open everything | A separate admin workstation and account, App Control, Administrator protection, no email or browsing in the admin context | “A second device and account slow me down” | Real friction, by design |
| High-exposure roles (executives, finance, payments) | Targeted phishing, fraud, high-value data | Strictest Office and macro settings, App Control, ASR rules in block mode, tighter browser extension control | “I need it to just work, now” | A small, well-supported population with fewer choices |
Each of these mechanisms comes with its own standard argument, for and against.
Removing local admin and EPM. Packaging effort used to be the argument against, and auto-updates plus EPM have mostly taken care of it. Rule maintenance is what’s left: real work, but predictable work. Watch out for one current trap, though. Microsoft documents that Administrator protection doesn’t support elevations initiated from EPM, and the Windows security baselines have switched Administrator protection on by default since the October 2026 update. Roll the new baseline out to devices where standard users rely on EPM, and their elevations break. Keeping the groups apart avoids exactly that.
Attack surface reduction rules are the cheapest win on the list. The standard protection rules can usually go straight to block mode. The rest can break line-of-business apps, which is why Microsoft suggests about 30 days in audit mode first. Warn mode looks like the comfortable middle, but recent Defender versions need an administrator to approve the unblock, and some rules don’t support it at all. Exclusions per rule are cleaner.
App Control for Business is the strongest control here, since it decides what runs at all, SYSTEM processes included. It’s also the most work. Every new application, update or vendor certificate needs a rule, so I’d keep it for the small groups with the highest risk.
Office macros are partly done already, since Microsoft blocks macros in files from the internet by default. Going further, say blocking every unsigned macro, needs an inventory of old files and macros that hardly anyone has.
Administrator protection gives users who keep local admin rights a standard token, and every elevation needs Windows Hello. Expect prompts, lots of them. Elevated apps also run in a separate profile without single sign-on, and Windows 365 and Azure Virtual Desktop aren’t supported yet.
Third-party containment. Tools like BeyondTrust or ThreatLocker go further than Microsoft’s built-in options, for example by limiting what an elevated app may do afterwards. I wrote about that gap in my EPM post. They’re worth their price where your risk appetite or your regulator asks for it, usually for the high-exposure group.
Decide the tier, not the exception
Tiering only works if someone decides the tiers, and that’s the tricky bit. Risk sits with the CISO, impact with the business, effort with IT. All three need a say, yet nobody wants every browser-extension request in front of the management committee.
So split the decisions by level. The committee decides once which user groups exist and which baseline each group gets. After that, two kinds of request remain. A request that fits within a group’s settings is handled by IT, quickly and without a meeting. A request to move someone into a different group, for example a finance analyst who wants developer freedoms, is a decision for that person’s line manager, who then also carries the risk.
Nobody should design those baselines from scratch. CIS Benchmarks, which many Swiss organisations already use, come in two levels. Level 1 is a base recommendation that can be implemented fairly quickly while keeping systems usable. Level 2 is defence in depth for environments where security is paramount, and CIS warns that it can cause problems if applied carelessly. That maps well onto the groups: Level 1 as the floor for everyone, Level 2 for admins and high-exposure roles. Microsoft’s own security baselines are the other common starting point, and they’re easier to deploy through Intune.
A benchmark also helps with audits. The question changes from “what did IT configure?” to “which deviations did you accept, and who signed them off?”. That’s the same logic as the tiers.
The catch is that a benchmark is still one setting per level, and it has no idea your developers need Docker. The list of accepted deviations per group is where the real work happens. It’s also the document your auditor will ask for.
The defaults are moving anyway
The interesting part about Office macros is how the block finally happened. The macro inventories didn’t get any better. Microsoft changed the default, and organisations had to deal with the result. The same is happening now with Administrator protection, which arrived in the Windows security baselines this October, whether or not you were ready for it.
I’d expect more of that. And each time, an estate with one configuration for everybody has two choices: accept the new default everywhere and deal with the complaints, or switch it off everywhere and fall behind. An estate with user groups has a third option. It can take the new default for the groups where it fits, and document the exception for the one where it doesn’t.
That’s the part I’d want to have in place before the next default changes. Choose your groups and their baselines while you still get to choose.