For twenty years, enterprise security rhythm has been set by the patch cycle. A vendor publishes fixes, security scores them, IT schedules them, and the backlog gets worked in order of severity. Patch Tuesday was the metronome.
That model assumed something that’s no longer true: that vulnerability discovery was slow, human, and scarce.
It isn’t anymore. AI models can now find sophisticated flaws across massive codebases at machine speed; Anthropic’s Mythos-class models demonstrated this at scale through Project Glasswing, surfacing thousands of zero-days in weeks, and that capability is now generally available with the release of Claude Fable 5. And Anthropic is already moved past, as we see OpenAI’s GPT-5.5-Cyber, MDASH, and others proliferating the market and driving scalability of vulnerability detection as well as exploit.
The numbers tell the story: mean time to exploit a disclosed vulnerability has compressed from roughly 32 days in 2022 to just hours while enterprise mean time to remediation for complex applications sits above five months. One recent vulnerability analysis put it bluntly: the system isn’t behind and catching up, it’s architecturally mismatched to attacker velocity. When that’s true, reactive patching stops being a strategy. It becomes triage.
The strategic response isn’t to patch faster. It’s to need fewer patches by keeping your estate close enough to current that fixes are always available and the upgrade path is always short. That’s a lifecycle policy, not a patching policy. And the benchmark is N-1.
What does an N-1 policy mean?
N-1 means every piece of software in scope runs either the current major version (N) or one major version behind (N-1). It’s a posture, not a project: a standing commitment that nothing in your estate drifts more than one version from supported, patchable currency.
The case for it has always existed: supportability, compatibility, audit posture. What’s new is the security math. Software at N or N-1 receives fixes within days of disclosure. Software at N-3 may wait, may receive a degraded backport, or may receive nothing. Software past end-of-life will never receive a fix, every flaw an AI finds in it is permanent.
In the old world, that gap was theoretical for most of your estate. In the new world, assume everything will eventually be scanned by someone.
Staying current avoids the extended support tax
There is also a financial reason to treat N-1 as an operating discipline: extended support is the tax organizations pay for letting technology age past its useful life. When critical software falls behind, teams lose negotiating leverage, upgrade paths get harder and the business is forced to pay premium support fees just to keep antiquated technology minimally protected. That spend does not modernize the estate. It does not improve resilience. It simply buys time around a problem that proactive asset management could have reduced, if not eliminated.
A current, accurate view of every product, version, lifecycle date and exposure tier changes that equation. ITAM can identify which assets are approaching end-of-life before they become emergency exceptions. Security can understand which outdated systems create the most exposure. Finance can see where extended support spend is avoidable. Together, those teams can shift from reacting to unsupported technology to planning upgrades, replacements and retirements on a predictable cadence.
The point is not to eliminate every legacy system overnight. It is to stop treating extended support as a normal cost of operations. Every dollar spent keeping unsupported technology alive is a dollar not spent on modernization, resilience or better business outcomes.
N-1 gives organizations a practical standard for staying current enough that fixes are available, risk is visible and extended support becomes the rare exception, not the recurring penalty.
The three-tier framework
A flat N-1 mandate across the whole estate fails on contact with reality. Upgrades cost money and carry risk, and not all software carries equal exposure. Tier the policy:
Tier 1: Externally facing applications
Web apps, APIs, customer portals, VPN and remote access, edge and perimeter infrastructure.
This is the surface attackers—and their AI tooling—can probe directly without ever breaching you. It earns the strictest standard: N or N-1 only, with upgrade SLAs measured in weeks, not quarters. Anything in this tier past N-1 should appear on the same dashboard as open critical vulnerabilities, because functionally, that’s what it is.
Tier 2: Operating systems, databases, and application frameworks
The platform layer: server and client OS, database engines, runtime environments, middleware, application frameworks.
A compromise here doesn’t take down one application, it undermines everything built on top. Hold this tier to N-1 with defined, calendar-enforced upgrade windows.
The discipline that matters most: schedule upgrades on the vendor’s release cadence, not on your incident cadence. If you only upgrade a database when something breaks, you’ll always be three versions behind when something breaks.
Tier 3: Internal, low-exposure applications
Internal tooling, isolated systems, software with no external surface and contained blast radius.
Pragmatism applies. Risk-accepted N-2 is defensible here, but “risk-accepted” is doing real work in that sentence. It requires a documented exception, a named owner, and a scheduled review. Undocumented drift is not risk acceptance; it’s risk ignorance.
Two triggers that override the tiers
The tiers set the baseline. Two conditions jump the queue regardless of tier:
- End-of-life is a hard stop: EOL software cannot be brought to N-1 because there is no N to upgrade to within that product line. It can’t be patched, only replaced or isolated. The threat data is unambiguous: vulnerabilities in EOL systems are roughly four times more likely to be weaponized, and nearly half of known exploited vulnerabilities trace to outdated, unsupported software. Regulators have noticed; CISA now requires US federal agencies to affirmatively retire unsupported edge devices, not just patch around them, and expect that posture to spread into commercial compliance frameworks. Treat every EOL asset as an open security finding with a remediation owner and a date, even in Tier 3. The riskiest software in most estates isn’t the unpatched current version; it’s the version no one can patch.
- Exposure outranks severity score: CVSS-driven prioritization optimizes for the wrong variable when discovery is cheap. A 6.5-severity flaw on an internet-facing API is a more urgent problem than a 9.8 on a system three network segments deep. Weight your queue by reachability first, severity second.
Prioritize lifecycle updates efficiently by stage and version
How this relates to CTEM
If your security team runs a Continuous Threat Exposure Management program—Gartner’s five-stage framework of scoping, discovery, prioritization, validation, and mobilization—an N-1 policy isn’t a competing idea. It’s the layer underneath.
CTEM answers “what should we fix first?” by ranking exposures on real exploitability and business impact instead of raw CVSS scores. Lifecycle currency answers a prior question: “when we decide to fix it, will a fix exist?” A CTEM program can prioritize flawlessly and still stall when the top finding lands on software that exited support two years ago, there’s nothing to mobilize toward. An estate held at N-1 keeps every prioritized finding remediable, which is what makes the mobilization stage actually work.
One honest caveat: version currency is one exposure class among several. It won’t fix misconfigurations, identity sprawl, or excessive permissions, exposures attackers exploit just as readily. But it’s the exposure class that determines whether patching is possible at all, it’s the one ITAM uniquely owns, and it’s the one most organizations measurably neglect.
What this policy requires (and where most programs fail)
An N-1 policy is only as good as the data underneath it. Enforcing it requires answering four questions, continuously and authoritatively, for every asset:
- What is it? Normalized product identity, not five spellings of the same vendor across five discovery tools.
- What version is it? Reconciled, current, trusted version records.
- Where is it in its lifecycle? Release dates, end-of-life dates, end-of-support dates from an authoritative catalog, not a wiki page.
- What’s its exposure? Internet-facing or internal; which tier it belongs to.
This is where most programs quietly fail. The policy gets written, the tiers get agreed upon and then nobody can produce a reliable report of which assets are out of compliance, because the inventory is fragmented and the lifecycle data is stale. The policy becomes a document instead of a control.
Authoritative lifecycle intelligence (knowing every product, every version, and every end-of-life date across the estate, normalized into one consistent view) is the unglamorous infrastructure that makes the entire framework enforceable. It’s also what turns the conversation between ITAM and security from finger-pointing into a shared operating rhythm: ITAM owns the ground truth and the lifecycle data; security owns the exposure tiers, the validation, and the SLAs; both work from the same report. If security is running CTEM, this is ITAM’s seat at that table.
Identify and prioritize version updates by discrepancy
Where to start this quarter
You don’t need the full framework live to make progress. Three moves, in order:
- Run the EOL report. Identify everything in the estate past end-of-life today. This is your permanent-vulnerability list, and it’s almost always larger than leadership expects.
- Tier your externally facing applications. You can’t enforce Tier 1 SLAs until you know what’s in Tier 1. Exposure mapping is the fastest-value exercise on this list.
- Pick one Tier 2 platform and put it on a cadence. One database engine, one OS family. Prove the upgrade rhythm works before scaling the policy.
The era of AI-speed vulnerability discovery is not coming, it arrived this spring. The organizations that fare best won’t be the ones that patch fastest. They’ll be the ones with the least to patch.
Want to know how much of your estate is past end-of-life right now? Flexera can help. That answer should take minutes, not a discovery project. If it doesn’t, that’s the gap to close first.
