How do you patch or mitigate CVE-2023-21529 (Microsoft Exchange Server Deserialization of Untrusted Data)?

CISA’s required action for CVE-2023-21529 is to apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable. In practice, find every instance of Microsoft Exchange Server 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.

What this CVE means for Exchange Server patching

CVE-2023-21529 is a Microsoft Exchange Server deserialization of untrusted data issue, so the practical question is whether any Exchange instance in your environment is still reachable in a way that can be abused. For this class of flaw, the first decision is not whether the system is “important,” but whether it is still exposed, patched, or constrained by a vendor-supported mitigation path.

Start by identifying every Exchange deployment, including on-premises servers, hybrid roles, test systems, and forgotten edge instances. That inventory step matters because remediation is only effective if you can prove there are no unmanaged copies left behind, especially where older servers remain online solely to support mail flow or coexistence.

How to apply the fix or mitigation safely

The normal remediation path is to apply the vendor security update or the documented mitigation exactly as provided, then verify that the server is no longer vulnerable in the configuration that was actually deployed. If the environment cannot accept the fix immediately, remove direct internet exposure, constrain access paths, or disable the affected service until the workaround is in place.

When a workaround is the only option, treat it as a temporary risk reduction measure rather than a substitute for patching. You should confirm that the mitigation is still active after restarts, certificate changes, proxy updates, or configuration management runs, because Exchange environments often drift back toward the vulnerable state when administrators focus only on service continuity.

For practitioners comparing remediation sources, the most useful references are the vendor advisory for exact build and mitigation instructions, and the CISA Known Exploited Vulnerabilities Catalog for the current KEV handling of the issue. If you are validating the record itself, the CVE Program and the NIST National Vulnerability Database are the authoritative catalogues to check.

What to do if patching must wait

If you cannot patch right away, the priority is to reduce exploitability, not to “watch and wait.” Restrict inbound access to Exchange as tightly as operationally possible, remove unnecessary internet-facing paths, and place compensating controls around the service so that only the smallest required set of users and systems can reach it.

If the service cannot be made acceptably safe under the available mitigation, discontinuing use is the correct choice. That is especially true for legacy Exchange deployments that persist only because they are convenient, because a vulnerable mail server with broad network reach is a long-lived exposure point, not a short-term exception.

Risk and Threat Considerations

Exchange deserialization flaws are attractive because they can turn a reachable service into a foothold for code execution or deeper compromise. The main danger is not just exploitation on the server itself, but the downstream access that a compromised mail platform can provide into mailboxes, tokens, adjacent systems, and administrative workflows.

Failure mechanism: Untrusted serialized input is processed in a way that allows an attacker to influence object construction or execution paths, so exposure depends on reachability and on whether the vulnerable instance is still accepting the risky input pattern.

Impact: Successful exploitation can lead to server compromise, mailbox and credential exposure, lateral movement, and a larger recovery effort if the Exchange host sits near identity, messaging, or directory infrastructure.

Standards & Framework Alignment

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

NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.AM-01 — Asset Inventory	Exchange remediation starts with knowing every server instance in scope.
Recommendation — Maintain a complete inventory of Exchange servers and exposure paths before remediation.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The CVE requires confirming exposure and validating that mitigation removes the flaw.
	SI-2 — Flaw Remediation	Patching or applying the vendor mitigation is the primary corrective action here.
Recommendation — Scan Exchange assets and verify the vulnerability is remediated or constrained. Apply the vendor fix or approved mitigation and track completion to closure.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	This issue requires asset discovery, prioritization, and timely remediation of a known exploited flaw.
Recommendation — Prioritise the Exchange CVE for rapid remediation and confirm the result.
ISO/IEC 27001:2022	A.8.8 — Management of Technical Vulnerabilities	The question is about patching and mitigating a known server vulnerability.
Recommendation — Track, assess, and remediate the Exchange vulnerability under technical vulnerability management.

Practitioner Guidance

What to prioritise: Treat complete Exchange inventory and exposure removal as the first task, then patch or mitigate in place. An untracked server is often the real blocker, not the update itself.

What to verify: Confirm the exact server is covered by the vendor fix or mitigation, then validate that the effective exposure has changed, not just the documented configuration. A control that looks correct on paper but is still reachable from the internet is not a finished remediation.

Decision rule: If you can patch, patch first and verify. If you cannot patch, shrink exposure immediately and keep the workaround under change control until the server is updated or retired.

Practitioner takeaway: For Exchange vulnerabilities, the safest response is usually to remove uncertainty quickly, prove the server is no longer exposed, and then close the exception only after the environment is verifiably back inside supported bounds.