How do you patch or mitigate CVE-2021-36942 (Microsoft Windows Local Security Authority (LSA) Spoofing)?

CISA’s required action for CVE-2021-36942 is to apply updates per vendor instructions. In practice, find every instance of Microsoft Windows in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What CVE-2021-36942 Means for Patch Planning

This is a Windows exploitation and remediation question first: the flaw matters because it was used in the wild, so patch priority should follow exposure, not convenience. The first decision is whether every affected Windows instance can be updated now, or whether you need a temporary containment path while you work through change windows and dependency checks.

Because the direct answer points to vendor updates or documented mitigation, the operational task is to confirm where Microsoft Windows is running, verify which systems are actually exposed, and then apply the vendor action consistently across endpoints, servers, and any image or template that may reintroduce the vulnerable state.

If you need a broader process for triage, emergency mitigation, and post-patch verification, the Zero-Day and Exploited Vulnerabilities Guide is the right starting point for an exploited vulnerability response workflow.

Mitigation When Immediate Patching Is Not Possible

When you cannot patch immediately, the practical fallback is exposure reduction, not reassurance. If the system can be isolated from the internet, that should be treated as a temporary containment measure, and if it cannot be safely contained or updated, taking it out of service is the safer option than leaving a known exploited vulnerability in production.

That decision is especially important where the Windows host is externally reachable, supports administrative access, or sits on a path to higher-value systems. In those cases, mitigation should be paired with access review, because reducing reachability only helps if remote paths to the vulnerable host are actually closed.

A documented enterprise patch workflow is easier to execute when the inventory and prioritisation model is already in place, which is why a Vulnerability Management Guide is useful for handling the asset-scope and exception side of the response.

For Windows systems specifically, hardening the endpoint baseline around exploit resistance, credential protections and logging improves your ability to absorb the remediation window. The Windows Endpoint Hardening Guide is relevant where the mitigation depends on reducing abuse paths before or alongside patch deployment.

How to Check for Earlier Abuse After Remediation

After patching, the question is not only whether the update installed, but whether the flaw was already used to establish access or move laterally. Review authentication events, service creation, privilege changes, and any unusual logons around the period when the vulnerable system was exposed, then correlate those events with endpoint or EDR alerts where available.

This review should focus on whether the affected host showed signs of abnormal interactive access, new local administrators, unexpected service activity, or log tampering. If the system was internet-facing or exposed for a long period, assume compromise assessment is part of remediation, not an optional follow-up.

The most useful supporting evidence is in the Windows event trail itself, especially logon and account-management activity. The Windows Event Log Guide helps anchor that review in the right event IDs and audit paths.

Risk and Threat Considerations

This vulnerability is risky because active exploitation changes the normal patching calculus. A known exploited Windows flaw can be used to gain a foothold before defenders complete routine remediation, so delay increases the chance that the fix arrives after the system has already been abused.

Failure mechanism: An attacker abuses the LSA spoofing weakness to interact with the target Windows system in a way that can expose credentials, support impersonation, or enable follow-on access before normal detection catches up.

Impact: The practical impact is potential host compromise, credential exposure, lateral movement, and the need for broader incident response if logs or endpoint signals indicate earlier exploitation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The issue is a known exploited vulnerability requiring prioritised remediation.
Recommendation — Prioritise and verify remediation of the vulnerable Windows assets.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question is about applying vendor updates or mitigation for a software vulnerability.
	AU-6 — Audit Review, Analysis, and Reporting	Post-patch review of logs is needed to detect earlier exploitation.
Recommendation — Track, test, and apply the required Windows security update or mitigation. Review logs for indicators of abuse before and during remediation.
NIST CSF 2.0	PR.IP-12 — Vulnerability Management	The response depends on timely identification, prioritisation, and remediation of exposed systems.
	DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software	Checking for earlier exploitation requires monitoring evidence from the affected Windows estate.
Recommendation — Maintain a remediation workflow that drives fast action on exploited vulnerabilities. Correlate host and authentication telemetry to spot suspicious activity around exposure.

Practitioner Guidance

What to prioritise: Patch every reachable Windows instance first, then move to isolated or harder-to-reach systems that still represent a recovery or re-entry risk. If a system cannot be patched promptly, treat exposure reduction as a short-lived bridge, not a long-term workaround.

What to verify: Confirm the vulnerable product is actually present, confirm the update or mitigation was applied, and confirm the host did not regain exposure through a gold image, VM template, or unattended rebuild path.

Decision rule: If the machine has business-critical exposure and no vendor fix can be applied immediately, remove internet reachability or retire the system from service before accepting the risk of leaving a known exploited flaw open.

Practitioner takeaway: For an exploited Windows vulnerability, remediation is only complete when patching, exposure reduction, and post-patch compromise review have all been done together.