Security Debt Compounds Too

Technical debt is a familiar idea.

A shortcut saves time today.

Someone promises to clean it up later.

Later becomes next quarter.

Next quarter becomes next year.

Eventually the shortcut becomes part of the environment.

Cybersecurity has its own version of this problem.

Call it security debt.

One deferred patch.

One undocumented firewall rule.

One old administrator account.

One temporary exception.

None of those things may create a crisis by themselves.

But they accumulate.

And eventually everything becomes harder to understand and harder to secure.

Security Debt Is Usually Boring

Security debt rarely announces itself with dramatic music.

It often looks like:

We'll patch that next maintenance window.

Nobody knows what that server does, so leave it alone.

That account is probably still needed.

Don't delete the firewall rule. Something might break.

We'll update the documentation later.

That operating system is old, but the application still works.

Each decision may have a reasonable explanation.

The problem appears when the exception never goes away.

Debt Creates Friction

Imagine investigating an alert.

You find a strange server.

Nobody knows who owns it.

The operating system is unsupported.

Its firewall rules are undocumented.

Several administrator accounts exist.

The monitoring agent stopped working months ago.

The asset inventory says the server was retired.

Now the investigation is harder.

Not because the attacker was especially sophisticated.

Because the environment itself is difficult to understand.

That is one of the costs of security debt.

Old Systems Create More Decisions

Legacy systems are a common example.

An old application may be necessary for business operations.

Replacing it may be expensive or complicated.

That is reality.

But the risk does not disappear because replacement is inconvenient.

Now additional decisions may be required:

• Can the system be isolated?
• Can access be restricted?
• Can monitoring be increased?
• Can unnecessary services be removed?
• Can the data be moved?
• Is a replacement plan documented?
• Who accepts the remaining risk?

The longer modernization is deferred, the more compensating controls and exceptions may accumulate around the system.

Temporary Fixes Become Architecture

Suppose a project needs a quick firewall exception.

Then another service depends on it.

Then an integration is built around it.

Then nobody wants to remove it because nobody knows what will break.

The temporary rule is no longer temporary.

It has become architecture.

That is how debt compounds.

A workaround that survives long enough can become something the environment depends on.

At that point, removing it becomes harder than creating it was.

Documentation Debt Is Security Debt

Documentation is easy to neglect because nothing immediately breaks when it becomes outdated.

But during an incident, missing information suddenly matters.

Which system is this?

Who owns it?

Which application depends on it?

Which ports are supposed to be open?

Where are the backups?

Who has administrator access?

What changed yesterday?

Every unanswered question slows response.

Asset inventories, network diagrams, ownership records, and system documentation help defenders understand relationships, dependencies, and expected behavior.

Documentation has security value.

Alert Debt Exists Too

Security teams can accumulate unresolved alerts.

Maybe the alert is noisy.

Maybe nobody owns it.

Maybe it has been firing for months.

Eventually people stop paying attention.

The alert still exists.

The detection still exists.

But its operational value has collapsed.

That is another form of debt.

A useful detection should lead to some expected action.

If nobody knows what to do when it fires, the detection itself may need attention.

Access Debt Exists Too

The same idea applies to permissions.

Over time, users change roles.

Projects end.

Vendors leave.

Service accounts remain.

Temporary privileges become permanent.

Now ask:

• Which privileged accounts are still necessary?
• Which users have access they no longer need?
• Which API keys are still active?
• Which SSH keys still work?
• Which vendor accounts remain enabled?
• Which exceptions were supposed to expire?

Access that accumulates without review becomes another form of security debt.

Security Debt Is Not the Same as Negligence

This distinction matters.

Organizations make tradeoffs.

Resources are limited.

Some risks are knowingly accepted.

Some remediation takes time.

A legacy system may be necessary.

A patch may require testing.

A business dependency may prevent immediate change.

The problem is not that every issue must be fixed immediately.

The problem is unmanaged accumulation.

Debt needs to be:

• Visible
• Owned
• Prioritized
• Reviewed
• Reassessed

A problem that cannot be fixed today can still be managed today.

Plans Need Dates and Owners

NIST SP 800-171 Rev. 3 recognizes that some deficiencies may need to be managed through documented plans of action and milestones rather than pretending every issue can be resolved immediately.

That is a useful principle even outside environments where that specific standard applies.

Instead of:

Fix later

write:

Issue:
Unsupported operating system

Owner:
Infrastructure Team

Risk:
Unsupported platform may contain unpatched vulnerabilities

Mitigation:
Restricted network segment and limited access

Replacement target:
Q2 2027

Review:
Monthly

Now the debt is visible.

Visibility makes management possible.

Accepted Risk Still Needs Attention

Sometimes an organization decides not to fix something immediately.

That does not mean the issue disappears.

A useful risk decision should still answer:

What is the issue?

What risk does it create?

Why are we not fixing it now?

What controls reduce the risk?

Who approved the decision?

When will we review it again?

Risk acceptance should be a decision.

Not the absence of one.

Small Maintenance Prevents Large Cleanup

Security programs sometimes focus heavily on major initiatives.

New tools.

New frameworks.

New architecture.

Those can matter.

But routine cleanup matters too.

Disable unused accounts.

Remove stale firewall rules.

Patch systems.

Delete old credentials.

Update diagrams.

Review permissions.

Retire unnecessary services.

Close resolved exceptions.

None of this looks revolutionary.

That is the point.

Maintenance prevents complexity from becoming permanent.

Measure What Is Accumulating

One way to make security debt more visible is to track it.

For example:

Unsupported systems: 4

Temporary exceptions past expiration: 7

Dormant privileged accounts: 3

Unresolved critical vulnerabilities: 5

Firewall rules without owners: 12

Stale asset records: 8

The exact metrics will vary.

The goal is not to create another dashboard for the sake of having a dashboard.

The goal is to make unresolved security decisions visible enough that they can be managed.

Your Home Lab Can Accumulate Debt Too

Look at your own lab.

Do you know why every VM exists?

Which ones are still used?

Which ports are open?

Which SSH keys still work?

Which containers are running?

Which projects were abandoned?

Which packages need updates?

Which old snapshots still exist?

Which documentation is out of date?

You can check running containers with:

docker ps

Check listening services with:

ss -tulpn

Check available package updates on Ubuntu with:

apt list --upgradable

Then clean up what you no longer need.

Document what remains.

A clean lab is easier to learn from.

A clean environment is easier to defend.

Create a Small Security Debt List

For your home lab, create:

security-debt.md

You might track items like:

# Security Debt

## Old VM
**Issue:** Ubuntu test VM no longer used  
**Risk:** Unnecessary attack surface and maintenance  
**Owner:** Me  
**Action:** Delete VM  
**Target:** October 15  

## SSH Key
**Issue:** Old laptop key still authorized  
**Risk:** Unnecessary authentication path  
**Owner:** Me  
**Action:** Remove key  
**Target:** October 10  

## Documentation
**Issue:** Network diagram does not include new server  
**Risk:** Inaccurate asset visibility  
**Owner:** Me  
**Action:** Update diagram  
**Target:** October 12

Now you are not simply noticing problems.

You are managing them.

Security Debt Has Interest

Technical debt is often described as having interest.

The same idea applies here.

A forgotten account today may require a simple cleanup.

Years later, nobody may know whether deleting it will break an application.

An undocumented firewall rule today may take five minutes to document.

Years later, removing it may require hours of testing.

An old system today may need a normal upgrade.

Years later, it may require a complete application replacement.

The longer uncertainty remains, the more expensive change can become.

That is the interest on security debt.

Key Takeaway

Security debt is rarely one catastrophic mistake.

It is often the accumulation of small unresolved decisions.

Old systems.

Temporary exceptions.

Unused accounts.

Stale documentation.

Ignored alerts.

Deferred maintenance.

Each one adds friction.

Eventually the environment becomes difficult to understand and expensive to change.

You do not need to eliminate every imperfection immediately.

You do need to know what you are carrying.

Because security debt compounds too.

Verified References

• NIST SP 800-171 Rev. 3
  Includes requirements related to account management, least privilege, vulnerability remediation, configuration management, and plans of action for managing unresolved security requirements.
  https://csrc.nist.gov/pubs/sp/800/171/r3/final

• NIST Cybersecurity Framework 2.0
  Emphasizes ongoing identification, governance, protection, detection, response, and recovery activities rather than treating cybersecurity as a one-time project.
  https://www.nist.gov/cyberframework

• CISA Cybersecurity Performance Goals
  Provides practical guidance around asset inventories, account security, vulnerability management, logging, network security, and other foundational practices that help reduce unmanaged security risk.
  https://www.cisa.gov/cybersecurity-performance-goals

This article is intended for educational purposes. Security risks, exceptions, and remediation timelines should be evaluated according to the requirements and operational needs of the environment where they exist.