OS hardening & security baselines

Legacy protocol lockdown, credential protection, PowerShell controls and deployable security baselines — itemised on a written plan, deployed in your own Intune tenant, and reversible item by item.

Why this matters

A freshly enrolled Windows device still speaks protocols designed for networks that no longer exist. LLMNR and NetBIOS broadcast name lookups that anything on the same segment can answer — poisoned responses that capture credential hashes remain a staple finding in penetration test reports. NTLMv1, RC4 and TLS 1.0 stay accepted across much of a typical estate until someone deliberately turns them off, and in most tenants nobody has, because the work is genuinely fiddly: dozens of individual settings, each delivered a different way, each with its own failure mode, and no natural owner.

The common end state is a tenant with a compliance policy, a PIN requirement and little else, described internally as "managed" — while credentials sit in LSASS unprotected on devices Credential Guard never reached, macro blocking rests on Office defaults that no policy enforces, and PowerShell executes with no record of what it ran.

What a good build does

Decolla treats hardening as discrete, itemised changes rather than one opaque bundle accepted on faith. This section of the catalogue spans legacy protocol and cipher lockdown, credential protection, PowerShell logging and language-mode controls, logon and macro hardening, and deployable Microsoft Windows and Edge baselines alongside community options from CIS, NCSC and OpenIntuneBaseline.

Every item lands on a written plan before anything runs, stating how it is delivered and its reversibility class, with anything irreversible flagged for explicit approval. Riskier lockdowns are staged rather than switched on wholesale: incoming NTLM restriction ships audit-first, so you read your own event logs before moving to deny. Credential Guard is hardware-gated, targeting only devices that can actually run it. Where an organisation genuinely needs an exception — the line-of-business installer that demands UAC off is the classic — it survives only as a flagged, documented exception recorded beside the canonical hardening item, never deployed alongside it. Config Refresh re-applies policy on a schedule so local tampering doesn't quietly unwind the work, and every change Decolla makes carries per-item rollback.

Where it bites people

Protocol lockdown breaks the thing nobody documented. Refuse NTLM or disable SMBv1 estate-wide and a decade-old multifunction printer's scan-to-folder, or a NAS on ancient firmware, stops authenticating — often days later, and the ticket says "scanning is broken", not "NTLM was refused". This is precisely why the plan is itemised and staging exists: audit before deny, and per-item rollback lets you revert the single implicated change while the rest of the hardening stays in place.

Baseline stacking produces a tenant nobody can reason about. Dropping a Microsoft baseline onto hand-built policies, or layering two community baselines at once, generates settings conflicts that Intune reports but does not explain. Decolla's plan shows exactly which baseline items are in scope before you approve them — and the Defender baseline is deliberately excluded from this section, because it lives in Endpoint protection, so the two never overlap.

What's in this section (27 items)

Reversibility: auto reverses when unassigned · reverse reversible with a documented step · irreversible flagged before you approve the plan.