Teams should only keep it with a documented exception, a named owner, compensating controls, and a migration deadline. The decision should be based on business criticality, exposure, and the dependency chain, not convenience. If the system supports customer, partner, or admin access, temporary tolerance should be short and tightly monitored.
Why This Matters for Security Teams
Keeping an old runtime is rarely just a technical choice. It is a risk acceptance decision that can affect patchability, exploit exposure, and the reliability of downstream applications. For security teams, the real question is whether the runtime is already operating inside a controlled exception process, with clear scope and a removal plan. That aligns with the governance mindset in the NIST Cybersecurity Framework 2.0, where risk decisions should be traceable to business objectives and monitored over time.
The biggest mistake is treating “temporary” as a vague promise instead of an enforceable control state. An old runtime can remain defensible for a short period if it is isolated, monitored, and tied to a specific migration milestone. It becomes difficult to justify when it supports internet-facing services, privileged workflows, or systems with brittle dependency chains that make patching seem expensive. In those cases, the runtime decision becomes part of the organisation’s attack surface management, not just platform engineering.
In practice, many security teams encounter runtime risk only after a vulnerability disclosure, not through planned lifecycle management.
How It Works in Practice
A defensible decision starts with inventory. Security teams need to know where the runtime is installed, which applications depend on it, whether it is customer-facing, and what breaks if it is upgraded. That dependency map should feed a formal exception record that names the business owner, the security owner, the approved duration, and the compensating controls. Without that, the runtime is just lingering technical debt.
A practical review usually asks four questions:
- Can the runtime be isolated from public access and high-privilege paths?
- Are there compensating controls such as WAF rules, segmentation, enhanced logging, and EDR coverage?
- Does the application handle sensitive data, administrative functions, or regulated transactions?
- Is there a realistic migration path to a supported version within a defined deadline?
For legacy systems, “good enough” often means reducing exploitability rather than eliminating risk. That may include restricting network reachability, removing unnecessary packages, enforcing strong authentication, and monitoring for known abuse patterns. If identities or service accounts rely on the runtime, teams should also review whether secrets are stored safely and whether privileged access is limited to only the accounts required for maintenance. This is where runtime risk can overlap with NHI governance, especially when automation, CI/CD jobs, or service credentials are tied to the application stack.
Security teams should also verify whether detection coverage is actually meaningful. A runtime exception without alerting, asset ownership, or patch verification creates false confidence. Where the runtime cannot be upgraded quickly, the decision should trigger additional testing of the dependency chain, rollback planning, and incident response readiness. Guidance is still evolving on how long these exceptions should last in complex environments, but best practice is clear that the deadline must be short enough to force action, not merely record intent. These controls tend to break down when the old runtime is embedded in a monolithic production platform with undocumented dependencies and no safe rollback path because the migration risk is then used to justify indefinite exposure.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, requiring organisations to balance reduced exposure against release friction and service disruption. That tradeoff is most visible in regulated or high-availability environments, where a hurried upgrade can create more risk than a short-lived exception. The right answer depends on whether the runtime supports a low-risk internal tool or a critical workload with external access.
There is no universal standard for how long an exception can remain open. Current guidance suggests the duration should reflect exposure, exploitability, and the speed at which the dependency can realistically be remediated. A backend batch job with no network exposure may justify a longer window than an admin console or API endpoint. By contrast, a runtime that supports partner access, payment flows, or identity-related functions should be treated much more strictly, especially if the environment also falls under NIST CSF outcome expectations for governance and monitoring.
Legacy runtimes also create hidden edge cases. Some applications cannot be upgraded because the vendor no longer supports the code path, while others depend on outdated libraries that are several layers removed from the main runtime. In those situations, security teams should document whether the real risk sits in the runtime itself, the embedded libraries, or the exposed service interface. When the stack also supports privileged automation, the team should check whether NHI or service account controls need to be tightened alongside the exception. If there is no credible migration plan, the safer decision is usually to retire or isolate the workload rather than keep extending the tolerance window.
Related resources from NHI Mgmt Group
- How do security teams decide whether an AI agent should keep access to regulated data?
- How do security teams decide whether to keep Cognito-like tools in scope?
- How should security teams decide whether to keep a legacy SEG or move to an API-based email security model?
- How should security teams decide whether to keep a legacy SEG with Microsoft 365?
