Security and Identity Debt: Measure and Pay It Down

Every shortcut taken to ship faster, from an admin role granted "for now" to a service account nobody owns, stays on the books until someone pays it off, and attackers collect the interest. Security debt is the accumulated gap between how your systems should be secured and how they are, and identity debt is the part of it made of accounts, roles, secrets and trust relationships. Most organisations track pieces of it in different places: a vulnerability backlog here, an exceptions log there, an access review spreadsheet somewhere else. This guide shows security leaders, IAM owners and risk managers how to bring those pieces into one debt inventory, score it so the worst items rise to the top, and burn it down with measurable progress that a board can follow.

Key takeaways

Debt is a portfolio, not a backlog. Treat unpatched systems, unsupported platforms, standing privilege, orphaned identities, long-lived secrets and open exceptions as one register with one scoring method.
Identity debt grows silently. Accounts and secrets are cheap to create and rarely removed, so their count drifts upwards unless offboarding and expiry are automated.
Score principal and interest. The principal is the effort to fix an item; the interest is the exposure it creates for every month it stays open. Prioritise high interest per unit of effort.
Stop new borrowing first. Burn-down fails if guardrails do not stop the same debt being created again, so pair every paydown campaign with a preventive control.
Report trend, not totals. Boards act on whether debt is shrinking and how old it is, so report net change, ageing and the share covered by an accepted, time-limited exception.

What counts as security and identity debt

The UK NCSC's secure development principles describe security debt as the security-relevant part of technical debt, giving the example of an application granted broad admin permissions during development instead of the permissions it actually needs, and advise keeping a register of that debt so you can return to it and see your cumulative exposure. That idea scales beyond software. In an enterprise, debt is any known, accepted-by-default weakness that persists because fixing it was deferred.

Debt class	Typical items	Where it is usually tracked today
Vulnerability debt	Findings past their remediation deadline, recurring misconfigurations	Vulnerability scanner, ticketing system
Platform debt	Unsupported operating systems, runtimes, appliances and firmware	CMDB, end-of-life lists
Identity debt: human	Dormant and orphaned accounts, leavers with residual access, standing admin rights, shared accounts	Directory reports, access review outcomes
Identity debt: non-human	Service accounts without owners, API keys and tokens with no expiry, over-scoped roles, credentials reused across environments	Often nowhere, or a secrets manager that covers only part of the estate
Control debt	MFA gaps, logging gaps, controls failed at audit and not yet fixed	Audit findings, plan of action and milestones
Exception debt	Risk acceptances that have expired or been renewed without review	Exceptions register

Non-human identity debt deserves particular attention because it maps directly onto several entries in the OWASP Non-Human Identities Top 10 for 2025: NHI1 Improper Offboarding, NHI5 Overprivileged NHI, NHI7 Long-Lived Secrets and NHI9 NHI Reuse. Each of those is debt in the sense used here: the fix is known, it was deferred, and the exposure grows over time.

Why identity debt behaves differently

Patch debt has a natural ceiling: a server either has the update or it does not, and vendors publish what is missing. Identity debt has no such ceiling and very little external signal.

Creation is cheap, removal is expensive: provisioning an account or minting a token takes seconds; proving it is safe to delete needs an owner, usage evidence and a change window.
Nobody reports it: no scanner advisory tells you that a service account has outlived the project that created it. You find it only by reconciling identities against owners and activity. See the NHI Inventory Reconciliation guide.
Privilege accretes: people and workloads gain roles as they change jobs or features, and rarely lose them. Standing privilege is debt that a JIT Access Guide approach retires.
It compounds with other debt: an unsupported server running under a domain admin service account with a password that never expires is three debts stacked, and the combined risk is far higher than any one alone.

The mechanics of finding dormant and orphaned human accounts are covered in the Orphaned and Dormant Accounts guide. This guide is about putting those findings into a portfolio alongside everything else.

Building the debt inventory

Do not build a new tool first. Build a single register, fed from the systems that already hold the evidence, with a small set of common fields. The Risk Register Template is a good base; the debt register adds the fields below.

Field	Purpose	Example
Debt ID and class	Group and de-duplicate items	ID-NHI-0142, identity debt: non-human
Asset or identity	What is affected	svc-backup-prod, Windows Server 2012 R2 host
Accountable owner	Who decides and funds the fix	Head of Infrastructure
Date first recorded	Drives ageing metrics	2025-03-14
Exposure factors	Inputs to the interest score	Internet reachable, privileged, touches regulated data
Principal estimate	Effort to fix, in days or a T-shirt size	M (5 to 15 person-days)
Linked exception	Shows whether the risk is formally accepted and until when	EXC-2026-031, expires 2027-01-31
Compensating controls	What reduces interest while the debt is open	Network isolation, credential vaulted with rotation
Target paydown date and status	Burn-down tracking	Q1 2027, in progress

Feed the register from the scanner (findings past deadline only, not every finding), the CMDB end-of-life fields, directory and cloud identity reports, the secrets manager, audit findings and the exceptions register. Keep each feed's original ticket as the system of record; the debt register is a portfolio view, not a replacement workflow. NIST SP 800-53 already expects this kind of record: CA-5 calls for a plan of action and milestones documenting planned remediation of weaknesses found in assessments, and PM-4 asks for a process so those plans are developed, maintained and reported across the programme.

Scoring debt: principal and interest

A CVSS score or an audit rating does not tell you which debt to pay first, because it ignores how long the item has been open, how hard it is to fix and how the items compound. A simple principal and interest model works well and is easy to explain to finance teams. The weights below are NHI Mgmt Group's suggested starting point; calibrate them against your own risk appetite.

Interest factor	Score 1	Score 3	Score 5
Reachability	Isolated segment	Internal, broadly reachable	Internet facing or third-party reachable
Privilege	Read-only, single system	Write access to one business service	Admin, domain, tenant or cloud-organisation level
Data and service impact	No sensitive data	Internal confidential data	Regulated data or a critical service
Exploit or misuse signal	None known	Public technique exists	Known exploitation, or credential found exposed
Age	Under 90 days	90 days to 1 year	Over 1 year

Add the factors for an interest score between 5 and 25, then divide by a principal score (1 for under a day of effort, 2 for under two weeks, 3 for larger projects). Sort by the result. Items with high interest and low principal, such as deleting an unused admin token, go first. Items with high interest and high principal, such as replacing an unsupported platform, need a funded project and compensating controls in the meantime. For a monetary view of the largest items, the Cyber Risk Quantification Guide explains how to express loss exposure in financial terms.

Compensating controls reduce interest, not principal

When a fix cannot happen soon, compensating controls lower the interest. The NCSC's guidance on obsolete products is a good model for platform debt: it recommends upgrading rather than continuing at risk, and where that is not yet possible, reducing the likelihood of compromise (blocking untrusted routes such as email and web browsing, removing non-essential services) and the impact (restricting access to sensitive data, network zoning, stronger logging and monitoring). Record those controls against the item and re-score it, but keep the principal unchanged so the debt never looks paid when it is only managed.

Paying it down: a phased approach

Freeze new borrowing (weeks 1 to 4): add guardrails that stop the commonest debt being created. Examples: a maximum lifetime on new API keys and tokens, mandatory owner and expiry fields when a service account is requested, joiner-mover-leaver automation tied to HR events, and a rule that any new exception has an expiry date. See the Security Exceptions and Risk Acceptance Guide.
Baseline (weeks 2 to 8): load the feeds, de-duplicate, assign owners and score. Expect a large unowned tail of non-human identities; give these a default owner (the platform team that hosts them) and a deadline for the real owner to be found.
Quick wins (months 2 to 3): disable, do not delete, unused identities and credentials with high interest and low principal. NIST SP 800-53 AC-2(3) expects accounts to be disabled when they have expired, are no longer associated with a person, violate policy or have been inactive for a defined period. Monitor for breakage for a set period, then delete. Keep a re-enable runbook as rollback.
Funded projects (quarters 2 to 4): package the high-principal items, such as platform replacement or migrating hard-coded secrets into a vault, into business cases that show interest avoided. Pair each with a dated exception so the risk is visibly owned.
Steady state: set a debt budget per business unit (for example, no growth in high-interest identity debt quarter on quarter) and review the register at the risk committee. Fold access review outcomes and audit findings into the register automatically.

Test every bulk change in a pilot scope first. Disabling a service account that a nightly batch job depends on is the classic failure, so check last-authentication data across every system the identity can reach, not only the directory, before disabling.

Decision guidance

Situation	Pay down now	Accept with compensating controls
Unused identity or credential	Yes, almost always: low principal, and removal leaves nothing to manage	Rarely; only during an evidence hold
Unsupported platform running a critical service	Plan and fund replacement	Yes, in the interim, with isolation and a dated exception
Over-privileged role in daily use	Right-size after usage analysis	Short term, with monitoring of privileged actions
Long-lived secret embedded in an application	Rotate and move to a vault or federation	Only with frequent rotation and usage alerting

Small organisations: a single spreadsheet register with the fields above, reviewed monthly by the person who owns IT, is enough. Start with admin accounts, leavers and unsupported devices, and use the Cyber Hygiene Checklist Guide to stop new debt. Large organisations: automate the feeds, report per business unit, and tie debt budgets to funding decisions so units that keep borrowing see the cost.

Detection and measurement

Measure the portfolio, not individual tickets. These metrics show whether debt is shrinking:

Net debt change: items opened minus items closed per month, by class. Sustained positive values mean guardrails are missing.
Weighted debt score: sum of interest scores across open items. Falling totals matter more than ticket counts.
Debt age: median and 90th percentile age of open high-interest items.
Ownership coverage: percentage of identities, human and non-human, with a named, current owner.
Exception hygiene: percentage of open debt covered by an unexpired exception, and number of exceptions past expiry.
Recurrence rate: items closed then reopened within 90 days, which signals a missing preventive control.

The Key Risk Indicators for Cyber Risk Guide shows how to set thresholds on these so they trigger escalation rather than sitting on a dashboard.

Framework mapping

Framework	Reference	How it relates to debt
NIST CSF 2.0	ID.RA-06	Risk responses are chosen, prioritised, planned, tracked and communicated: the debt register and burn-down
NIST CSF 2.0	GV.OV-03	Risk management performance is evaluated and adjusted: debt metrics at the risk committee
NIST CSF 2.0	ID.IM-01	Improvements identified from evaluations feed new debt items
NIST SP 800-53 Rev 5	CA-5, PM-4	Plans of action and milestones for weaknesses and their programme-level process
NIST SP 800-53 Rev 5	RA-7	Respond to assessment and audit findings in line with risk tolerance
NIST SP 800-53 Rev 5	AC-2(3), AC-6	Disable inactive and unassociated accounts; least privilege
NIST SP 800-53 Rev 5	SA-22	Replace unsupported system components or provide alternative support
CIS Controls v8.1	Control 5 Account Management	Managing credentials for user, administrator and service accounts
NCSC CAF	A3 Asset Management, B2 Identity and Access Control	Knowing what you have and who can access it
OWASP NHI Top 10 2025	NHI1, NHI5, NHI7, NHI9	Non-human identity debt patterns

Common failure patterns

Counting tickets instead of risk: closing a hundred low-interest items while one domain-level service account with a ten-year-old password stays open looks like progress and is not.
Paydown without guardrails: a clean-up campaign removes thousands of stale accounts, and a year later the count is back because provisioning never gained expiry or ownership.
Exceptions as permanent debt forgiveness: risk acceptances renewed every year without re-scoring hide debt instead of managing it. The Remediation SLAs and Vulnerability Exceptions Guide covers time limits.
Leaving non-human identities out: registers built from HR and the directory miss service accounts, tokens and cloud roles, which are often the most privileged and least watched part of the estate.
Deleting before disabling: removing identities without a disable-and-watch period causes outages that make business owners resist the next round.
No accountable owner: debt assigned to "IT" is debt nobody funds. Every item needs a named person who can approve the fix or accept the risk.

Practitioner checklist

Define the debt classes you will track, including human and non-human identity debt.
Stand up one debt register fed from scanner, CMDB, identity, secrets and exceptions sources.
Assign a named accountable owner to every item, with a default owner for unowned identities.
Score each item for interest and principal, and sort by interest per unit of effort.
Add guardrails that stop new borrowing: credential lifetimes, mandatory owners, exception expiry.
Disable, monitor, then delete unused identities and credentials, with a re-enable runbook.
Package high-principal items into funded projects with dated exceptions and compensating controls.
Report net change, weighted score, age and ownership coverage to the risk committee every quarter.

Security and Identity Debt Guide: Measuring and Paying Down Accumulated Risk