Extended support for one of the most widely deployed database platforms in enterprise history ended two weeks ago. Extended support for the server operating system it usually runs on ends in January. Every organisation with either of those in production has known about both dates for roughly a decade, and a large proportion of them will still be running them next summer. That gap, between a known deadline and an unmade decision, is what security debt actually is. The term gets used loosely to mean unpatched systems. It is more useful and more uncomfortable than that. Security debt is the accumulated set of decisions that were reasonable when they were made, were never revisited, and now carry a cost that grows quietly every year.
Four kinds, and only one of them is about patches
Platform debt is the visible sort: operating systems, databases and appliances past or approaching end of support. It is the easiest to inventory and the most expensive to clear, which is why it dominates the conversation while the other three go unmeasured. Identity debt is larger and almost never on anyone's list. Service accounts created for a project that finished in 2014 and still holding administrative rights. Contractors deactivated in the directory but still present in three applications. Permissions granted for a month-end close and never withdrawn. Shared credentials for a system whose vendor requires them. This debt accrues with every project and is paid down by nobody, because no one owns the cleanup. Architectural debt is the decisions embedded so deeply that they are no longer perceived as decisions. The flat network. The integration built with a domain administrator account because that was quickest. The application that requires an old authentication protocol, which then keeps that protocol enabled for everyone. Knowledge debt is the quietest and the most dangerous. The person who configured it has left. The documentation was never written, or describes a state three changes ago. The system is not insecure exactly; it is unknowable, and nobody will touch it in case it breaks.
The interest is the point
What makes debt a useful metaphor rather than a rhetorical one is compounding. An unsupported platform does not merely stay as risky as it was. It gets worse, because every new vulnerability disclosed against it is permanent, and because everything built afterwards integrates with it and inherits its constraints. The old authentication protocol kept alive for one application becomes the reason an identity modernisation programme cannot proceed five years later. The service account with excessive rights becomes the credential an attacker uses to move laterally in an incident nobody has had yet. And the principal is always repaid at the worst possible moment. Almost every organisation eventually pays its security debt during an incident, an acquisition or an audit, at emergency rates, under time pressure, with no ability to plan.
| Debt type | What to investigate |
|---|---|
| Platform | Unsupported operating systems, databases and appliances. |
| Identity | Forgotten accounts, shared credentials and excessive rights. |
| Architecture | Flat networks, privileged integrations and old authentication dependencies. |
| Knowledge | Missing owners, outdated documentation and undocumented changes. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Making it a ledger
The practical shift is from a risk register of adjectives to a debt register with numbers. Each item should carry five things: what it is, who owns it, when support ended or ends, what compensating control is in place today, and what removal would cost. That last figure is the one that changes the conversation, because it converts an argument about risk appetite into a comparison of two numbers. A register like that also makes the honest conclusion possible, which is that not all debt should be repaid. Some systems will run unsupported for years because replacement genuinely is not viable, and that is a legitimate decision provided it is isolated, monitored, documented and signed by someone with the authority to accept the consequence. What is not legitimate is the same situation arrived at by inattention.
Practical Guidance for a Legacy Risk Assessment
- Build one register covering all four debt types. Platform, identity, architecture and knowledge. Most organisations have a decent list of the first and nothing on the other three.
- Put a support expiry date and an owner on every platform item. A named individual, not a department. Debt without an owner does not get repaid.
- Price removal, not just risk. Replacement cost, migration effort, business disruption. Without the number, the decision defaults to doing nothing indefinitely.
- Audit service accounts and privileged access annually. Anything unused for ninety days, anything with rights nobody can justify, anything belonging to a finished project. This is the cheapest debt to clear and the most valuable in an incident.
- Isolate what you are choosing to keep. Network segmentation, restricted access paths, enhanced monitoring, no internet exposure. Unsupported and contained is a defensible position; unsupported and reachable is not.
- Write the decision down and have it accepted in writing. Risk acceptance by a named executive with a review date turns silent drift into a governed choice.
- Attack knowledge debt directly. Pay someone to document the three systems nobody understands before the person who half-remembers them resigns.
- Add a debt clause to new projects. Every new system arrives with a supported-until date, a decommissioning plan for what it replaces, and a named owner. Otherwise you are borrowing while trying to repay.
The Regional Angle
Gulf technology estates are younger than their European and American equivalents, which is usually presented as an advantage. It is, but it disguises the fact that debt here accrues faster, for reasons specific to how the region has grown. The dominant factor is expansion speed. A system implemented for one entity in one country is, four years later, serving eight entities across three countries, with each extension bolted on rather than designed in. The security assumptions made in the original design, about who is inside the perimeter, which network is trusted, which administrator is a single person, were made for a much smaller organisation and were never re-examined. That is architectural debt created by success, and it is the most common pattern I see in regional groups. The second factor is the delivery model. Most implementations here are project-based work by systems integrators, priced to a scope and closed at go-live. Documentation is a deliverable rather than a practice, configuration knowledge leaves with the project team, and the maintenance contract that follows covers availability rather than currency. Knowledge debt is therefore built into the commercial model, and the only defence is to make documentation and knowledge transfer a payment milestone rather than an appendix. Third, and underappreciated: a meaningful amount of regional legacy is mandated by counterparties. Government and ministry portals that require specific old browsers or browser plug-ins, customs and trade systems with their own client requirements, and bank host-to-host arrangements running on protocols and file formats agreed years ago. Organisations maintain an unsupported workstation or an old integration server because a regulator or a bank effectively requires it. That debt cannot be unilaterally repaid, which makes isolation the only available answer: a dedicated, segmented, heavily monitored machine that does that one job and nothing else, rather than a general-purpose desktop in finance. Fourth is workforce mobility, which converts ordinary staff turnover into permanent knowledge loss when the departing engineer leaves the country rather than moving to a competitor down the road. There is no informal call to a former colleague here. Finally, timing. The January operating system deadline lands in the middle of the regional budget year for entities running a calendar cycle, and procurement here rarely completes in a quarter. Anyone who has not started that work has, realistically, already decided to run unsupported for part of next year. That is survivable, but it should be an accepted and isolated position rather than a surprise in February.
The objection worth taking seriously
The objection is that the debt metaphor is a licence to defer. Financial debt has a schedule, a rate and a creditor who calls. Security debt has none of those, which means the analogy provides the comfortable part, the idea that carrying it is normal and prudent, without the discipline that makes debt manageable in finance. In practice, organisations that adopt the language use it to reclassify neglect as strategy, and the register becomes a document that gets longer every year while nothing is decommissioned. The stronger version is that the framing is unfalsifiable. If everything is debt, then the concept selects for nothing: a security team can point at any part of the estate and call it debt, and no prioritisation follows. Meanwhile the actual determinant of whether an old system hurts you is not its age but whether it is exposed and whether it holds anything worth taking, and plenty of unsupported systems sit quietly on isolated networks doing no harm at all while a fully patched, fully supported, badly configured cloud storage bucket loses a hundred million records. Both points land, and the response is to insist on the two things that make the metaphor do work. First, a repayment schedule: every item gets an owner, a date and an accepted position, which means the register forces decisions rather than recording anxiety. Second, prioritisation by exposure and value rather than by age, exactly as the objection suggests, which is why the register asks for the compensating control alongside the expiry date. Used that way, the concept earns its place, because it captures something a vulnerability scanner cannot: that the dangerous part of the estate is usually not the thing with the missing patch but the thing nobody owns, nobody understands and nobody is willing to touch.
Common Questions
Where should an organisation with no register start?
Service accounts and privileged access. It takes a fortnight, costs almost nothing, reduces real exposure immediately, and produces a list that makes the case for the rest of the work.
Is it ever acceptable to run an unsupported system?
Yes, when the alternative is genuinely unaffordable, provided it is isolated from the internet and from general user networks, monitored more closely than anything else, and accepted in writing with a review date.
Do extended security update programmes solve the problem?
They buy time and are worth purchasing when a migration is genuinely under way. They become expensive very quickly and are a bridge, not a destination. Buy them with a plan attached.
What should we expect over the next twelve months?
Expect the January operating system deadline to produce a visible wave of incidents through next year, concentrated in mid-market organisations that ran out of budget rather than time. Expect auditors and cyber insurers to start asking specifically about end-of-support inventories as a condition rather than an observation. And expect the identity side of the debt, the forgotten accounts and standing privilege, to feature in the year's largest breaches more often than the unpatched platforms everyone is worrying about.
Legacy Risk Assessment — we turn a vague sense that parts of the estate are old into a ledger with owners, dates and prices, so the systems you keep are the ones you chose to keep.