Should organisations prioritise runtime protection before they finish patching zero-days?

Yes. When exploit creation accelerates, waiting for patch completion leaves too much exposure. Organisations should prioritise runtime controls for high-value applications, then use patching and code fixes to close the root cause. This is a sequencing decision, not an either-or choice, because both controls serve different phases of risk reduction.

Why This Matters for Security Teams

When a zero-day is actively being exploited, patch completion is often slower than attacker movement. That creates a short but material window where the organisation may still be exposed even if remediation is already in progress. runtime protection helps close that window by reducing exploitability, limiting blast radius, and buying time for safe patch rollout across production estates.

This sequencing matters most for high-value applications, internet-facing services, and environments where patch testing or dependency coordination delays rollout. Runtime controls do not replace patching, but they can suppress the immediate conditions attackers rely on, such as arbitrary code execution, lateral movement, or privilege escalation. For broad prioritisation, vulnerability intelligence from the CISA Known Exploited Vulnerabilities Catalog is useful because it focuses attention on issues already known to be under active abuse.

In practice, many security teams discover the real exposure only after a public exploit lands, not when the patch advisory is first released.

How It Works in Practice

The practical decision is to treat runtime protection and patching as sequential controls with different jobs. Runtime controls reduce the chance that an attacker can turn the zero-day into an outage or compromise before engineering teams finish validation. Patching then removes the underlying flaw so the same weakness cannot be reused later. That combination is especially important where change windows are narrow, multiple dependent services must be tested together, or the asset cannot tolerate rushed updates.

Effective runtime protection usually means tightening the control plane around the vulnerable workload rather than waiting for the software vendor fix alone. Typical measures include:

Restricting exposed entry points to the affected application or container.
Applying behavioural or exploit-blocking controls at the host, workload, or network layer.
Reducing privilege so a successful exploit cannot immediately reach sensitive systems.
Increasing logging and alerting so attempted exploitation is visible during the patch window.

The strongest approach is to align runtime control strength with exploit likelihood and asset criticality. That is why sources such as the FIRST EPSS model and the CISA Known Exploited Vulnerabilities Catalog are useful in prioritisation, while NIST SP 800-190 Container Security is relevant where the vulnerable service runs in containerised environments and runtime exposure must be controlled across images, hosts, and orchestration layers.

These controls tend to break down when the organisation assumes patch backlog can be offset by generic monitoring alone, because visibility without containment still leaves the exploit path open.

Common Variations and Edge Cases

Tighter runtime control often increases operational friction, so teams have to balance immediate containment against application availability and release speed. That trade-off is real, especially for legacy systems, regulated production services, and applications that depend on fragile third-party integrations. The right answer is not always “block harder”, but rather “block enough to reduce exploitability until the root cause is fixed”.

There is also a meaningful distinction between public-facing zero-days and internally exposed flaws. Internet-facing assets usually justify faster runtime intervention because exploitation can begin before defenders complete validation. Internal applications may still need containment, but the urgency can be lower if exposure is limited and compensating controls are strong. Best practice is evolving toward risk-based sequencing instead of one universal patch-first rule.

Another edge case is when the patch itself is risky or incomplete. In those situations, runtime protection becomes the primary near-term safeguard, while patching is staged through a controlled change process. The clearest signal that runtime controls need to stay in place longer is when exploit activity remains active in the wild or when rollback risk is higher than the residual exposure from temporary containment.

For teams managing large fleets, the useful question is not whether runtime or patching is better in theory, but which control can reduce loss fastest without creating a larger operational failure.

Risk and Threat Considerations

The material risk is the gap between exploit availability and patch deployment. Once a zero-day becomes weaponised, attackers only need one reachable instance and one successful execution path, while defenders may need testing, dependency coordination, maintenance windows, and rollback planning. That asymmetry makes untreated runtime exposure especially dangerous for critical services.

Failure mechanism: Attackers exploit the vulnerable code path before the patch lands, then use whatever the runtime environment still permits, such as code execution, privilege escalation, token theft, or lateral movement. If the organisation has no compensating runtime control, the vulnerability remains fully actionable during the patching delay.

Impact: The result can be service compromise, data exposure, persistence, or a broader incident that spreads beyond the original vulnerable workload. In regulated or customer-facing environments, the operational impact often includes emergency change work, incident response overhead, and degraded trust in the organisation’s ability to contain active exploitation.

Standards & Framework Alignment

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

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST Zero Trust (SP 800-207) 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	Prioritises rapid mitigation of exploited weaknesses while patching catches up.
	CIS 8 — Audit Log Management	Runtime protection needs visibility to detect attempted exploitation during the patch window.
Recommendation — Use CIS 7 to rank exploited zero-days by risk and enforce compensating controls until patched. Use CIS 8 to log and alert on exploit attempts while containment is in place.
NIST Zero Trust (SP 800-207)	SC-7 — Network Segmentation and Policy Enforcement	Zero trust containment limits blast radius when a vulnerable service cannot be patched immediately.
Recommendation — Apply policy enforcement to restrict reachability to exposed workloads until remediation completes.
NIST CSF 2.0	PR.PT — Protective Technology	Runtime protections are compensating controls that reduce exposure before root cause fixes land.
	RS.MI — Mitigation	Patching and runtime containment are both mitigation actions during an active zero-day period.
Recommendation — Deploy protective technology to reduce exploitability before patch completion. Execute mitigation in parallel, containment first and patching second.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	The question centers on exposed services that attackers can exploit before patches land.
	T1210 — Exploitation of Remote Services	Runtime controls help interrupt exploitation of remote-facing services while fixes are pending.
Recommendation — Hunt for T1190 activity and harden the exposed application path immediately. Monitor remote service abuse and restrict vulnerable service access until patched.

Practitioner Guidance

What to prioritise: Prioritise runtime containment first for internet-facing or high-value assets when exploit activity is credible, then patch as soon as validation allows. If the control can reduce exploitability today, it belongs in front of the patch queue.

Decision rule: If the zero-day is already being exploited, treat patching as necessary but insufficient on its own. If the asset is low exposure and patching can be completed safely within the same operational window, runtime controls may be lighter, but they should still be explicit.

What to verify: Confirm that runtime controls actually block the attacker path you care about, not just generate alerts. A control that only detects exploitation after execution has started is not a substitute for containment during a live zero-day window.

Practitioner takeaway: The right sequence is to reduce immediate exploitability first, then remove the flaw, because active adversaries do not wait for patch cycles to finish.