Should organisations treat legacy systems differently from modern workloads?

Why This Matters for Security Teams

Legacy systems should not be treated as if they behave like modern workloads because they often cannot support the same credential lifecycle, telemetry, or revocation speed. That matters most when a service account, API key, or certificate outlives the system that uses it, creating access that is technically valid but operationally stale. The problem is not just age; it is mismatch between old design assumptions and current identity governance.

Current guidance suggests separating these systems into a distinct control path, because forcing them through standard IAM workflows usually produces gaps in auditability and emergency response. NHI Management Group’s research shows that 71% of NHIs are not rotated within recommended time frames, while 80% of identity breaches involved compromised non-human identities such as service accounts and API keys in the Ultimate Guide to NHIs — What are Non-Human Identities. That pattern becomes worse when the workload cannot support modern secrets management.

In practice, many security teams encounter legacy identity exposure only after an outage, audit finding, or incident has already proved that the “temporary” exception became permanent.

How It Works in Practice

The practical answer is to treat legacy systems as a constrained identity tier with compensating controls, not as a full participant in the same lifecycle as cloud-native services. Modern workloads can often use workload identity, short-lived tokens, and runtime policy decisions. Legacy platforms may only support static secrets, local accounts, or infrequent certificate updates, so the control objective shifts from ideal lifecycle management to risk containment.

For modern systems, the preferred pattern is to issue ephemeral credentials per task, bind them to workload identity, and evaluate access at request time. The SPIFFE workload identity specification is a useful reference for this model, because it focuses on cryptographic proof of what the workload is rather than just who requested access. For legacy systems, teams often need to wrap access with gateways, vault brokers, certificate proxies, or jump hosts that impose controls the application itself cannot enforce.

That approach usually includes:

• Inventorying legacy assets separately, with explicit ownership and business criticality.
• Replacing long-lived shared secrets with the shortest feasible TTL, even if true JIT is not possible.
• Putting compensating logging, session recording, and approval controls around privileged access.
• Restricting network reachability so stale credentials cannot be used broadly.
• Planning migration toward workload identity patterns described in the Guide to SPIFFE and SPIRE.

In parallel, organisations should use the machine identity baseline from SailPoint’s Critical Gaps in Machine Identity Management report to justify tighter governance for assets that still depend on manual tracking, because 61% of organisations still rely on spreadsheets or manual processes. These controls tend to break down when a legacy system is embedded in a high-throughput integration path because access approvals, certificate renewal, and break-glass use become too slow to match operational demand.

Common Variations and Edge Cases

Tighter control on legacy systems often increases operational overhead, requiring organisations to balance risk reduction against availability and support burden. That tradeoff is real, especially where the system is business-critical, vendor-managed, or too fragile for frequent configuration changes.

Best practice is evolving, but there is no universal standard for how much exception handling is acceptable. Some environments can move legacy access behind a PAM or gateway layer with strong session controls, while others must keep static credentials temporarily and compensate with segmentation, rotation, and monitoring. The key is to avoid pretending that legacy systems can meet the same control objectives as cloud-native workloads when the underlying technology cannot.

One common edge case is a mainframe or on-prem application that cannot consume modern token-based identity. Another is a third-party appliance with hard-coded local accounts or fixed certificates. In these cases, organisations should define explicit expiry dates for the exception, document the compensating controls, and review whether the system can be fronted by a broker that converts old authentication into a managed access flow. The 91.6% figure for secrets remaining valid five days after notification in the Ultimate Guide to NHIs — Standards underscores why exception paths need aggressive review.

Legacy systems are different not because they are less important, but because they are less flexible, and that limitation should be reflected directly in policy, tooling, and incident response.

Related resources from NHI Mgmt Group

• When should organisations treat an NHI as a high-priority risk?
• How do organisations reduce manual provisioning risk in legacy applications?
• Why do legacy IGA tools create more risk for smaller organisations?
• Why do non-human identities create audit risk in modern environments?