A vendor appliance in the municipal data center has a critical patch, but a change freeze blocks immediate installation. Which interim mitigation best reduces exposure until the patch window opens?

Change freezes protect operational stability in municipal environments, but they do not erase published critical vulnerabilities on vendor appliances. When immediate patching is blocked, compensating controls reduce the reachable attack surface until the approved window opens. Microsegmentation and tighter network controls—ACL narrowing, management-plane isolation, jump-host-only admin paths, and removal of unnecessary routes—limit which hosts and identities can talk to the unpatched device. That approach aligns with Security+ compensating and preventive techniques: you accept temporary residual risk while shrinking exposure rather than pretending the CVE is irrelevant.

Ignoring the advisory because a freeze exists confuses process with risk acceptance. Freezes constrain change velocity; they do not magically neutralize exploitability, and governance still expects documented interim mitigations. Publishing the management interface on the Internet so the vendor can patch "without tickets" expands exposure dramatically and bypasses change, access, and remote-admin controls. Deleting the appliance from inventory only hides the finding from reports; it leaves the real device vulnerable and creates inaccurate asset and vulnerability management data that auditors and responders will rely on later.

Exam caveat: expect distractors that equate paperwork (inventory deletion) or convenience (open remote management) with mitigation. True interim mitigation constrains reachability and privilege around the unpatched asset. Operationally, document the freeze exception path, implement the segmentation changes with logging, verify only authorized management stations can reach the appliance, and schedule the vendor patch as a freeze-exception or next window with evidence of the compensating control while waiting.