Security Debt Is the Modernization Deadline You Don't Control

← All posts

Every other date in your modernization plan is negotiable. Vendor end-of-support, a regulator’s remediation window and a published CVE are not.

A CVE gets published on a Tuesday. It is a 9.8, remote code execution, no authentication required, and it affects a component inside an application your business cannot operate without. Your policy says thirty days for a critical. Security opens the ticket. The application team reads it, looks at the patch, and comes back with the sentence that ends the conversation: the fix requires a runtime version the application will not start on.

That is the moment security debt stops being a metaphor. Everything else in your portfolio can move. You can slip a release, defer a phase, re-baseline a roadmap, tell the steering committee the target architecture now arrives in FY28, and nobody outside the building notices. You can do none of that with a vendor’s end-of-support date, a regulator’s remediation window, or an attacker who has read the same advisory you have.

Here is the claim. Security and compliance are the only forces that reliably convert modernization from an aspiration into a dated commitment, which makes them the most effective source of program urgency available to you. Most CIOs treat that urgency as something that happens to them. It should be something they schedule.

The mistake is waiting for the audit finding to supply the deadline. An audit finding is the cheapest deadline you will ever be handed, because it arrives with a remediation window, an executive sponsor and a budget conversation already half won. It is only cheap if you get there first. The same obligation discovered by a regulator, a customer’s third-party risk questionnaire or an incident responder costs an order of magnitude more, and arrives with your name attached.

Why legacy systems are structurally unpatchable, not just unpatched

There is an assumption buried in most vulnerability management programs: that a patch exists, that it can be applied, and that the only variables are scheduling and testing. For a meaningful slice of your estate none of that is true, and the program has no way to represent it. “Unpatched” implies a backlog and a resourcing problem. “Unpatchable” is an architectural property, and it does not resolve with more people.

The six ways a patch path disappears

The vendor stopped shipping fixes. The obvious case, though end-of-support rarely arrives as one event. Mainstream support ends, then extended support, then security updates for a subset of severities, then nothing. Each step narrows what “patched” means, and the CMDB records only the last date somebody typed in.

The patch requires a platform the application cannot run on. The fix exists, but targets a runtime the application was never certified against. .NET Framework 4.8 applications carrying COM interop and 32-bit dependencies do not simply move to .NET 8. Java 8 applications built against internal APIs sealed in Java 9 do not simply move to 21. The vulnerability is in scope; the remediation is a port.

The regression test does not exist and cannot be recreated. The failure mode nobody writes on the risk register honestly. The patch would probably work. The person who understood the batch reconciliation well enough to certify that it still balances retired in 2019. What blocks the change is not the change. It is the absence of anyone who can say the change was safe.

The dependency graph no longer resolves. Rebuild a Python 2 application whose packages were pulled from an index that has since removed them, or a RHEL 6 host whose repositories are dark. The transitive closure of a twenty-year-old application includes artefacts that no longer exist anywhere you can reach. You cannot patch a build you cannot perform.

The build environment is gone. The compiler needs a license server that was decommissioned. The Delphi component vendor went out of business and the runtime DLL has no source. The build ran on a machine under a developer’s desk and no image was captured. Some organizations discover this during an incident.

Cryptography does not fit the field. A password column sized for a legacy hash cannot hold a modern one. A protocol frame with a fixed-length certificate field cannot accommodate a larger key. A partner integration hard-codes TLS 1.0 and the OS has no newer implementation. SHA-1 signing that cannot be replaced without reissuing every credential downstream. These are schema and protocol changes that ripple into every integrated system.

The 30-day SLA quietly becomes a multi-quarter program

Each failure mode has the same effect. A patch priced at a few engineer-hours and a change window turns out to be a project with an architecture phase, a test strategy and a budget line.

What happens next is the real problem. The organization raises a risk acceptance, with an owner, a compensating control, an expiry and a review cadence. Six months later it is rolled forward, because nothing changed. Then again. Then the owner moves roles and the successor inherits an item they did not create and cannot resolve.

Within two years the entry is permanent furniture. It still has a review date, which is the part that fools people, because a date implies a plan. Count how many of your top twenty accepted risks have been rolled forward more than four times. That is your real security debt, and it is the number a regulator will ask for.

Compensating controls have a half-life, and nobody is tracking it

Segmentation, WAFs, virtual patching, jump hosts, allow-listing, egress filtering, enhanced monitoring on the affected subnet. These are legitimate, and a security team that deploys them quickly is doing its job. They are also a bridge with a load limit, and the load limit is not written on the bridge.

How controls decay

A compensating control is calibrated against a system, a threat model and a network at a point in time. All three move. The control does not.

WAF rules are tuned to current request patterns. The application changes, the rules throw false positives, someone adds an exclusion for a broken workflow, and it is never revisited. Virtual patching depends on a vendor continuing to write signatures for a platform they have also declared end-of-life. Segmentation degrades through exceptions: a project needs a path into the isolated segment, the exception is granted for eight weeks, and eleven months later the firewall rule is still there with a ticket number in the comment field.

Then the human layer. The engineer who understood why the jump host existed leaves, new joiners find a faster path, and nobody does anything wrong. The control has simply stopped being a control.

The operational tax nobody re-examines

Controls accumulate. Each is individually cheap and collectively expensive, and the cost is paid in a currency your finance system does not track: change lead time, deployment friction, exception paperwork, three approvals to reach a server. The honest question is not whether each control was justified when added. It is whether the total cost of the stack, plus the residual risk it does not remove, now exceeds the cost of removing the system that requires it. For systems years past end-of-support the answer is usually yes, and almost nobody has done the arithmetic.

The specific moment the bridge fails

• An authenticated flaw. Perimeter controls assume the attacker is outside. A vulnerability requiring valid credentials is untouched by the WAF, and credentials are the most reliably available thing on the market.
• An insider path. Segmentation is designed against lateral movement from a compromised endpoint. It does little against a user with legitimate access to the segment.
• A supply chain compromise. The control assumes malicious traffic arrives from a hostile direction. A trojanized update from a trusted vendor arrives through the change process, signed and approved.
• A stale exception. The segmentation gap opened for a project in 2023 that nobody revoked. The most common finding in post-incident reviews of otherwise well-segmented estates.

Compensating controls buy time, which is a good purpose. The failure is treating purchased time as a resolution and never spending it on the thing it was bought for.

The regulatory clock: what DORA, NIS2 and PCI DSS 4.0 actually demand

Regulators have shifted, and the shift is the point. The older generation asked whether you had a policy. The current generation asks you to demonstrate, with evidence, that a specific control operates on a specific system, and to prove you can recover it under adverse conditions. A system nobody in the building fully understands cannot be demonstrated to be controlled, because demonstration requires someone able to describe the control, produce its evidence, and show it was tested.

What “demonstrable” costs you

Read the right-hand column again. Almost none of those failures are about the presence of a vulnerability. They are about the absence of evidence. You cannot produce an access review for a system where seventeen people share one privileged login. You cannot classify an incident inside a reporting window if the application writes no useful logs. You cannot demonstrate recovery for a system that has never been restored anywhere except itself, on hardware nobody sells.

That is why regulatory pressure is a better forcing function than vulnerability counts. A CVE can be argued about. An inability to produce evidence cannot, and it converts directly into a finding with a date on it.

Context, not hook: exploitation of vulnerabilities in older, unsupported technology has been widely reported as rising sharply year over year, and around 74% of manufacturers still run legacy systems (The Manufacturer / Intoware). That is why this argument now lands in more sectors at once, as NIS2’s scope pulls industrial operators into a regime that used to apply mostly to banks.

Your SBOM request is a modernization project wearing a compliance costume

SBOM expectations have moved from federal procurement into commercial contracts and sectoral regulation. The request sounds administrative. List what your software is made of. Try it on a system built in 2003.

Modern tooling reads manifests: a pom.xml, a package-lock.json, a container layer. Legacy estates frequently have none, and instead have four conditions that defeat the tooling.

• Vendored dependencies. A library copied into the source tree in 2011 and modified. It reports a version that no longer corresponds to anything upstream, and its security fixes diverged permanently.
• Forked components. Someone patched an open source library, never upstreamed it, and the fork kept the original name. Your scanner either misses real vulnerabilities or reports ones that were locally fixed. Both destroy trust in the report.
• Statically linked binaries. No manifest at all. Establishing contents requires binary analysis, and the result is probabilistic.
• Lost source. The executable runs in production and the repository was on a server retired during a datacentre consolidation. More common than anyone admits, and it usually surfaces during an SBOM exercise rather than before one.

Generating an accurate SBOM requires rediscovering the system’s composition, and that rediscovery is the first phase of modernizing it. When a customer or regulator asks for one, they have inadvertently funded your dependency archaeology.

If you do only one thing, retrofit identity

Of all the security work available on a legacy estate, identity retrofit has the best ratio of risk removed to application code touched. It is usually achievable without modifying the application, and it removes a class of risk rather than a specific vulnerability. It also produces something the other work does not: an audit trail. That single output resolves a surprising share of ITGC, PCI and HIPAA findings.

The patterns that work

Identity-aware reverse proxy for HTTP applications. The proxy terminates the session, enforces OIDC or SAML against your IdP, applies MFA and conditional access, and forwards a pre-authenticated request. The application either continues to believe it authenticates users itself, or is switched to trust the proxy. Azure AD Application Proxy, an OIDC-enforcing gateway, or an internally run proxy layer all produce the same shape.

Brokered access for everything else. 3270 emulators, thick clients, Oracle Forms and direct database access do not fit that pattern. The equivalent is a privileged access broker: the user authenticates with SSO and MFA, the broker holds the target credential and injects it, and the session is recorded. On z/OS, PassTicket generation from an authenticated session gives you time-limited single-use credentials without changing RACF-facing application logic.

Centralized authorization at the gateway. Once traffic passes a policy enforcement point, coarse-grained entitlement decisions move out of the application. You will not get fine-grained authorization this way, but the “any authenticated user can reach the admin path” problem is usually solvable immediately.

Where these patterns break

Header-based trust is an authentication bypass waiting to happen. The common implementation has the proxy inject a header such as X-Remote-User and the application trust it. If the application is reachable by any path that does not traverse the proxy, an attacker sets the header themselves and becomes any user, including an administrator. Mitigate with all four of: mutual TLS between proxy and application, a signed short-lived token rather than a plain header, network policy permitting ingress only from the proxy, and binding the listener so no other route exists. Then test the bypass explicitly, from inside the segment, as part of acceptance.

Session handling stays broken. The proxy issues an eight-hour session; the application issues one that never expires. A user logs out at the IdP and their application session survives, which means deprovisioning does not deprovision. Applications that accept a session identifier from the request and never regenerate it after authentication remain vulnerable to fixation, because their own session logic is unchanged. Align lifetimes, implement back-channel logout where supported, and have the proxy strip and reissue session cookies at the authentication boundary.

The shared service account. Very common and very damaging: the application connects to its database as one account for all users, or operations staff share a privileged login. The proxy knows who the user is; the application and database do not. Partial remedies are still worth taking. Carry verified identity in a signed header the application logs even if it does not enforce on it, so the trail exists at the gateway and correlates with database activity by timestamp. Put shared credentials behind a checkout process with session recording, so shared use becomes attributable. Neither is as good as named accounts, and both are defensible in an audit in a way that “seventeen people know the password” is not.

Embedded credentials. Passwords in JCL, connection strings in web.config, credentials inside stored procedures, keys in COBOL copybooks, service account passwords in scheduler definitions. Sweep across source, job libraries and configuration, because the inventory is always larger than expected. Move what you can into a vault with an agent that materializes the secret at process start. Anything that cannot be rotated without an outage should be recorded as a modernization requirement rather than a security exception, because “this credential cannot be changed” is the definition of an unrecoverable compromise.

The honest limit: identity retrofit does nothing about an unauthenticated flaw in the application once an attacker has network access, and nothing about the unsupported runtime underneath. It buys time and evidence, not absolution, and you should say so when you present it. A security leader who oversells a control loses the room for three years.

How to quantify this for the board without theatre

Boards have seen too many cyber risk numbers with no derivation. Figures in the tens of millions, produced by multiplying an industry average by an asset count, get discounted by anyone with a risk background. A smaller defensible number beats a large indefensible one. Build it in three lines and show your working.

1. Scope. What data does this system hold, how many records, and what would an intruder reach from it? Not the enterprise. This system and its blast radius.
2. Cost anchor. Use a published benchmark and adjust. IBM’s Cost of a Data Breach 2025 puts the average healthcare breach at $7.42M and financial services at $5.56M. State the source, say you are using it as an order-of-magnitude anchor, and show how you scaled it.
3. Likelihood, expressed honestly. Do not manufacture a probability. Use a band and name what drives it: internet exposure, whether a public exploit exists, whether authentication is required, whether any control interrupts the path.

Then say the sentence that actually moves budget.

That unlocks funding more reliably than any model, because it is specific, falsifiable and impossible to defer without someone accepting it in writing. Directors are comfortable accepting quantified risk. They are markedly less comfortable signing an acceptance for a risk with no mitigation and no plan, particularly under NIS2, where accountability is personal. Keep the finance mechanics light here; expected-loss reduction belongs in the full capital case, which is a separate paper.

A scoring model for sequencing security-driven modernization

Everything cannot be first. The teams that succeed have an explicit, arguable ranking that survives a steering committee, rather than a list ordered by whoever complained most recently. Score each system 1 to 5 on five dimensions, then weight.

1. Internet exposure (weight 3). 5 = reachable from the public internet or a partner network; 1 = internal only, behind multiple authenticated hops.
2. Data sensitivity (weight 3). 5 = regulated personal, health or cardholder data at volume; 1 = non-sensitive operational data.
3. Blast radius (weight 2). How much of the estate is reachable from a full compromise, including credentials it holds and systems that trust it.
4. Patchability deficit (weight 2). 5 = no patch path, unsupported runtime, build cannot be reconstituted; 1 = supported and current.
5. Time-to-EOL urgency (weight 2). 5 = past end-of-support or under twelve months; 1 = more than three years of supported life left.

Maximum is 60. Add two override rules, because arithmetic hides the cases that matter most. Any system scoring 5 on exposure and 4 or above on patchability deficit goes to the top regardless of total. Any system that cannot produce an access review enters the current audit cycle, because that is a control deficiency rather than a risk.

A worked example: five systems at a mid-sized insurer

Composite, but assembled from patterns that recur in most estates of this size.

The result is the useful part, because it is not the ranking most executive teams expect.

The policy administration mainframe, the system that dominates every architecture discussion and carries the largest blast radius, comes fourth. It is well isolated, IBM still supports the platform, and its patchability deficit is about people and regression testing rather than availability of fixes. It remains a serious long-term modernization priority. It is not a near-term security priority, and conflating those two things has delayed more urgent work at more organizations than any other mistake in this area.

First place goes to an unglamorous file transfer gateway nobody presents to the board. Partner-facing, running an operating system whose support ended years ago, holding credentials for a dozen broker connections, never rebuilt since the engineer who configured it left. It also trips the override rule, so it would be first even if the arithmetic disagreed.

Run this across your top thirty systems with security, architecture and application owners in one room. It takes a day, and produces a far more durable argument than a heat map, because every cell is a number somebody defended out loud.

End-of-support risk is a governance discipline, not a spreadsheet

Most organizations have an EOL list. Very few have an EOL calendar that functions as a governance artefact, and the difference determines whether you are ever surprised. A list records dates. A calendar has an owner, appears in a governance forum on a fixed cadence, and carries actions with a named accountable executive. It should look eighteen to twenty-four months forward, because anything inside twelve months is no longer a planning horizon. It is an incident with a countdown.

Treat extended support as a purchased option with an expiry. Extended security update programs are legitimate and often correct. They also typically escalate in cost year over year, frequently by a large multiple, precisely because the vendor is pricing them to end. Book it as what it is: a fixed-term option that converts a hard deadline into a slightly later hard deadline. Attach the remediation milestone to the same budget line, so the extension and the exit are approved together. An extension bought without a plan is a deadline you paid to lose sight of.

Negotiate from a position of having a plan. Vendors price bespoke support and migration assistance according to how trapped you appear. An organization arriving with a dated exit plan, a scoped alternative and approval to execute gets materially better terms than one asking what the extension costs. Your account manager works out which conversation is happening within five minutes.

Fold third-party EOL into supplier governance. DORA makes the third-party register explicit, but the discipline applies everywhere. You need the support status of components inside your suppliers’ products, not just your own estate, and the mechanism is contractual: notification obligations for component end-of-life, SBOM provision, defined remediation timelines for critical vulnerabilities. Add these at renewal rather than attempting an estate-wide re-papering, which never finishes.

Frequently Asked Questions

Isn’t isolating the system permanently cheaper than modernizing it?

Sometimes, and where it genuinely is, do it and say so plainly. The test is total cost over remaining life: the control stack, the friction it imposes on every change, the annual effort of evidencing it, escalating support fees, and the residual expected loss the controls do not remove. Isolation is a strong answer for a system with a short remaining life and a shrinking user base. It is a weak answer for one still receiving change requests, because every change erodes the isolation and nobody re-measures it.

Our auditors have accepted this risk for three years. Why is now different?

The standard changed underneath you. Older audit practice asked whether a risk was identified, owned and accepted. Current regimes ask you to demonstrate that a control operates and can be evidenced, and DORA and NIS2 add resilience testing and personal accountability on top. A risk acceptance rolled forward six times is now itself the finding, because it shows your risk process cannot resolve risks. It also reads badly in an incident review, where the question is not whether you knew but how long you had known.

Does an extended support contract solve the problem?

It converts an immediate deadline into a later one and buys scheduled time, which is genuinely valuable. It does not solve the problem. Coverage usually narrows to critical severities, so medium-severity issues accumulate unpatched. Cost escalates steeply, because the vendor wants the program to end. And the contract has a terminal date after which there is no option at any price. Buy it, spend the time on remediation, and put the exit milestone on the same approval as the purchase.

Do we really need an SBOM for a mainframe application?

You need to know its composition, which is the point of an SBOM regardless of format. Mainframe estates rarely produce a clean CycloneDX or SPDX document without real work, but the underlying questions are answerable: which third-party products and utilities sit in the runtime path, what versions, which are still supported, and which modules came from a vendor that no longer exists. Start with that inventory. The format matters when a contract requires it; the inventory matters immediately, because it tells you where you are exposed.

What is the fastest security win in the first 90 days?

Put your highest-exposure legacy application behind an identity-aware proxy with SSO and MFA, then verify it cannot be reached by any path that bypasses the proxy. That last clause is where these projects fail, so test the bypass explicitly from inside the segment. In parallel, run a secret scan across source, configuration and job libraries, because the embedded credential inventory is always larger than expected and it is the cheapest serious finding available to you. Both produce audit evidence inside the quarter.

The Bottom Line

Stop presenting modernization as a technology program with a security benefit attached. Present the security and regulatory obligation as the program, and modernization as the only remediation that durably closes it.

That is not a rhetorical trick or fear-selling. It is a more accurate description of what is happening. A system that cannot be patched, cannot be access-reviewed, cannot be restored into a test environment and cannot produce an SBOM is not a system with a modernization opportunity. It is an open finding nobody has written down yet.

Every other deadline in your portfolio bends. This one does not, and that is what makes it useful. The most reliable way to get a program funded, staffed and finished is to attach it to a date somebody outside your organization set, then get there before they do.

The audit finding is the cheapest deadline you will ever be given. The regulator’s version costs more. The incident responder’s version costs most, and by then the date is not yours at all.

If you want to know which systems in your estate have no patch path and no interrupting control, Modernize Software runs a two-week security debt triage that produces three artefacts: a scored ranking of your top thirty systems using the model above, a compensating control inventory with honest expiry dates, and an EOL calendar you can put straight into a risk committee pack. Most clients find the top-ranked system is not the one they expected.