Beyond Patching: Rethinking How We Manage Exposure

Imagine a CISO looking at a dashboard that shows 100% patch compliance. Everything is green. Three hours later, the SOC confirms that ransomware is moving laterally through the data center.

There is nothing contradictory about those two events.

An organization can remediate every known CVE and still leave attackers with excessive privileges, insecure configurations, legacy protocols, unnecessary services, unauthorized software, and years of accumulated configuration drift.

Patching addresses one source of exposure. It does not determine the overall security state of the device.

That is where conventional vulnerability management starts to break down. Security programs tend to organize work around findings: vulnerabilities, misconfigurations, excessive privileges, unauthorized applications. Attackers encounter none of those abstractions. They encounter a machine in a particular state, with a particular combination of software, privileges, services, policies, and controls.

Patching is one way to change that state, but it is far from the only one. A vulnerable component can sometimes be made materially harder to exploit by disabling the affected feature, restricting a service, removing unnecessary privileges, or changing the conditions the attack depends on. Other exposures, such as weak authentication settings, legacy protocols, excessive privileges, and unnecessary services, may have no patch to deploy in the first place.

This is where configuration management becomes a security control plane. The same mechanisms traditionally used to administer devices can be used to remove attack prerequisites, enforce compensating controls, harden exposed systems, and reduce risk when patching is irrelevant, unavailable, or operationally impractical.

But using another control plane does not solve the last-mile problem on its own. A patch can report successful installation. GPO can report successful processing. An MDM can show that a policy was correctly assigned. These are useful signals, but none necessarily establishes that the exposure is gone.

Consider a Windows fleet where Credential Guard is required. An Intune profile may be assigned across the entire in-scope population without Credential Guard actually running everywhere it should. Some devices may still require a restart. Others may have prerequisite or configuration issues that prevent the control from becoming effective.

Patching has the same problem. An update package can be delivered successfully while the vulnerable process remains loaded pending restart. Post-installation validation may reveal that the expected version never became effective at all.

Across thousands of devices, with software, policies, administrators, management systems, and operating conditions constantly changing them, apparent state and actual state can quietly diverge.

The practical objective is not to deploy the patch, assign the policy, or execute the configuration change. It is to remove the exposure and establish that the device actually reached the intended state. To manage exposure effectively, therefore, security teams need to work backward from that outcome rather than forward from the type of finding.

A Fix Has to Work With the Environment Around It

Getting a device into the right state once is only part of the problem. Enterprise endpoints are continuously being changed by policy, software, administrators, management tools, application updates, and normal operations.

A remediation platform might disable an insecure setting and verify that the change succeeded, only for an authoritative GPO to restore the previous value at the next policy refresh. An application update might re-enable a service that had been disabled as a compensating control. A device rebuilt from an older image might reintroduce settings that were corrected months earlier.

Simply applying the same fix again does not address what is happening.

What caused the setting to change determines how you should fix it. If GPO is enforcing the insecure value, the durable fix may belong in GPO. If an application requires the setting, changing it locally may break the application and the dependency needs to be addressed first. If the change was an approved exception, automatically reversing it may be the wrong action altogether.

NIST's guidance on security-focused configuration management reflects this lifecycle problem, covering the identification and implementation of configurations, configuration-change control, and ongoing monitoring rather than treating hardening as a one-time exercise.

This is where remediation starts to become an environment problem rather than a finding problem. The same exposure can require different corrective actions depending on what is enforcing the current state, what depends on it, and which control plane can change it safely.

To effectively manage exposure therefore you need more than the ability to execute a patch or change a setting. It needs enough context to understand how that device reached its current state, what is likely to happen after the change, and whether another management system will reinforce or reverse it.

That context is what makes it possible to choose the right intervention rather than repeatedly applying the most obvious one.

Knowing the Right Configuration Is Not the Difficult Part

The security industry already has extensive guidance on what secure configurations should look like. CIS maintains more than 100 secure-configuration Benchmarks across more than 25 vendor product families, developed through communities comprising more than 12,000 IT security professionals. 

The difficulty starts when those recommendations meet a production environment.

Consider Windows Print Spooler. Suppose a security team identifies an exposure affecting 8,000 Windows devices. The obvious response might be to patch every affected system and apply the recommended hardening. But the same exposure does not necessarily call for the same remediation everywhere.

Perhaps 2,000 of those devices are servers that have no legitimate need to print. Disabling the Print Spooler removes the exposed functionality altogether. Another 5,500 are employee workstations where printing is required.

For those devices, the better path may be to patch the vulnerability while tightening Point and Print restrictions, driver-installation controls, or other relevant settings. Meanwhile, the remaining 500 may support legacy printing workflows or applications that require additional testing before either change can be made safely.

The security objective is clear. The remediation path depends on what each device actually does.

Microsoft recommends thoroughly testing security baselines before production deployment because they change system security settings and can alter default behavior.

This is where configurations provide a particularly strong opportunity as a security control plane. It gives security teams options beyond waiting for every exposure to be resolved through a patch. A service can be disabled, functionality constrained, privileges reduced, or an attack prerequisite removed altogether.

The challenge is knowing which intervention makes sense for which devices. Eight thousand instances of the same exposure can resolve into several distinct remediation populations, each requiring a different combination of patching, hardening, compensating controls, or additional validation.

Making Remediation Safe Enough to Scale

Two Windows 11 devices with the same configuration violation cannot necessarily be treated the same when it comes to remediation.

One may be a standard knowledge-worker laptop. Another may run a finance application with a dependency on the component being changed. A third may be governed by a policy that will overwrite the correction. A fourth may support a production process where an unscheduled reboot is unacceptable.

The finding alone does not contain enough information to decide how the change should be executed.

Before broad enforcement, the organization needs to understand applicability, dependencies, conflicting controls, asset role, operational criticality, and the consequences of failure.

Devices with materially different characteristics should not automatically move through the same remediation path.

The rollout itself also needs evidence. A successful change should establish more than whether the setting changed.

Did the relevant service remain healthy? Did the device maintain connectivity? Did another policy subsequently restore the insecure value? Did the dependent application continue to function?

Rollback should also be part of the control model. This allows remediation to proceed without waiting for every affected device to fit the same change plan. Straightforward cases can move quickly, while devices with dependencies, conflicting policies, or greater operational sensitivity can be staged, tested, or routed through a different remediation path.

Remedio is designed around this operating problem: validating changes before broad execution, staging remediation where appropriate, verifying the resulting endpoint state, and providing rollback when a change produces an unacceptable operational result.

Remediation Should Break the Attack Path

Most attacks depend on more than the presence of a vulnerability. The attacker may also need a service to be reachable, a protocol to remain enabled, a privilege boundary to be weak, or a particular capability to be available.

Those conditions give defenders more than one opportunity to break the attack path.

CIS's Community Defense Model maps CIS Controls against real-world attack patterns and MITRE ATT&CK techniques. Its analysis identified CIS Safeguard 4.1, Establish and Maintain a Secure Configuration Process, as the most effective individual safeguard against the attack types analyzed.

The significance is broader than configuration hygiene. Security teams have multiple opportunities to interfere with the conditions an attacker depends on. The trick is identifying which intervention makes sense for a particular population of devices and then verifying that it actually removed the exposure.

This is where exposure management becomes more useful when it is connected to the mechanisms that can actually change the environment. Patching, configuration management, application control, privilege controls, policy enforcement, and other management planes provide different ways to remove or constrain the conditions an attacker needs.

An operationally aware remediation model can choose among those control planes based on the exposure, the affected device, its dependencies, and the consequences of the change. The goal is not to make every finding follow the same remediation workflow. It's to find a safe way to remove the exposure.

And there's the rub. Enterprises cannot manually determine the safest remediation path for every affected device. Nor should they have to.

This is where AI can make contextual remediation practical at enterprise scale. It can correlate those characteristics across large device populations, identify meaningful similarities, and separate affected devices into groups that can safely follow the same remediation path.

Remedio applies this model to the last mile of device security: understanding actual endpoint state, identifying which devices can safely receive the same corrective action, validating the change before broad execution, verifying the result afterward, and detecting when the environment moves out of that state again.

To wit, the City of Phoenix used Remedio to remediate more than 5,000 configuration risks were remediated in days. Within the first 30 days, the city reported an 83% reduction in attack surface and a 77% reduction in remediation time.

Security Posture Is a State, Not a Score

Patching remains essential, but it is one mechanism for changing device state. Hardening, privilege management, software removal, configuration enforcement, and compensating controls serve the same broader objective.

The real test is whether the organization can remediate exposure at scale without disrupting production, then keep the environment from drifting back into the same vulnerable state.

That requires knowing what is actually true on the endpoint, understanding what prevents or reverses a correction, separating devices that require different remediation decisions, validating changes before they spread, and verifying the resulting state afterward.

Vulnerability counts, closed tickets, deployment success, and patch-compliance percentages all describe parts of that process. None, on its own, establishes the security outcome.

Attackers encounter devices, not dashboards. Security programs should optimize for the same reality.

FAQ

About Author

Mor Bikovsky

Chief Business Officer

Mor draws on more than a decade of cyber and business strategy experience to lead Remedio's Business Strategy. Before joining Remedio, Mor led Global BD efforts for Claroty and filled a variety of key technology roles for Israel's intelligence services.