Isolate those systems, document the constraint, and grant only the minimum exception period needed for continuity. The goal is not to preserve long-lived certificates as a default, but to make every exception visible, justified, and time-bound so it does not become permanent.
Why short-lived certificates matter even when legacy systems cannot use them
Short-lived certificates reduce the time an exposed credential can be reused, which is why they are becoming the preferred baseline for modern systems. When a legacy platform cannot renew or trust them reliably, the problem is not just technical inconvenience, it is a weaker control boundary that increases the value of isolation, compensating controls, and a tightly bounded exception.
The practical question is how to preserve continuity without turning an exception into a standing operating model. That usually means treating certificate duration as a lifecycle control, not a convenience setting, and making the legacy gap explicit so teams can see where trust is weaker and where extra scrutiny is required.
That lifecycle view aligns with Machine Identity, PKI and Certificate Lifecycle Guide, which frames certificate expiry, renewal automation, and key protection as part of the same operational control surface.
How to contain the exception without weakening the wider estate
The safest pattern is to isolate the legacy system from broader trust relationships, then grant only the minimum certificate exception needed for continuity. Isolation limits what the old system can reach if the certificate is intercepted, copied, or abused, while a documented exception prevents the temporary gap from being hidden inside routine operations.
This is also where organisations should be deliberate about surrounding controls. If the system cannot participate in automated renewal, then compensate with stronger network segmentation, narrower access paths, tighter monitoring, and a clearly owned expiry date for the exception. The control goal is not to make the legacy platform modern, it is to stop its limitation from spreading risk across adjacent systems.
For a broader identity pattern, Ultimate Guide to NHIs — What are Non-Human Identities is useful because it places certificates alongside other machine-access mechanisms that must be governed with ownership and lifecycle discipline.
What makes these exceptions dangerous over time
Legacy certificate exceptions become risky when they quietly turn into permanent dependencies. Long-lived certificates increase the window for misuse, key compromise, stale trust, and forgotten renewals, and those risks compound when nobody can easily tell which systems still rely on them. The deeper the exception is embedded in operational flow, the more likely it is to survive after the business reason has gone.
A second issue is blast radius. If an exception certificate is reused across systems, shared between environments, or left outside a real rotation process, compromise of one legacy path can extend into many more. That is why exception handling must be time-bound and inventory-backed, not merely verbally approved.
The lifecycle risk is consistent with Sisense breach 2024, where credential-related exposure reportedly affected customer access material and showed how a single compromise point can widen into broader token and secret risk.
Risk and Threat Considerations
Legacy systems that cannot support short-lived certificates create a predictable exposure window for credential replay, interception, and stale trust. The risk is not only that the certificate lasts too long, but that the surrounding environment may treat it as normal, which makes compromise harder to notice and rotation harder to prioritise.
Failure mechanism: The legacy platform cannot renew, validate, or retire certificates on the modern lifecycle cadence, so operators extend certificate life or create manual exceptions that outlive the original constraint.
Impact: Attackers or insiders gain a longer opportunity to reuse a credential, and the organisation inherits a standing trust exception that can persist after the system’s operational need has changed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-57 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Certificate lifespan and renewal are governed by key lifecycle policy. |
| Recommendation — Set short cryptoperiods and enforce rotation or retirement before certificates become standing trust. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Legacy certificate exceptions are an authenticator lifecycle problem needing controlled issuance and retirement. |
| AC-4 — Information Flow Enforcement | Isolation of unsupported legacy systems depends on restricting where their long-lived certificates can be used. | |
| Recommendation — Manage certificate issuance, renewal, and revocation as controlled authenticator lifecycle events. Constrain legacy systems to limited flows and segregated trust paths. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Certificate handling is a cryptographic control requiring lifecycle governance and protection. |
| Recommendation — Apply cryptographic lifecycle controls to legacy certificate exceptions and document any deviation. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Long-lived certificates function as durable secret material and increase exposure when short-lived use is impossible. |
| Recommendation — Reduce lifetime, scope, and reuse of certificate material wherever legacy exceptions remain. | ||
Practitioner Guidance
What to prioritise: Classify each legacy certificate exception by business criticality, exposure, and expiry date. If the certificate can reach anything beyond a tightly bounded segment, treat it as a higher-risk exception even if the system itself is old and stable.
What to verify: Confirm that the system owner, approver, and review date are recorded, and that the exception is tied to a specific compensating control set rather than “temporary” wording alone. A good exception is measurable, reviewable, and removable.
Common mistake: Teams often preserve the certificate pattern while forgetting to preserve the control discipline. The result is an exception that behaves like a permanent credential policy, which defeats the purpose of short-lived issuance.
Practitioner takeaway: If a legacy system cannot support short-lived certificates, the decision is not whether to accept weaker security, but how tightly you can confine that weakness so it remains visible, bounded, and reversible.
Related resources from NHI Mgmt Group
- When does a short-lived API key still create material risk?
- Should organisations prioritize short-lived certificates before replacing VPNs and bastions?
- How should organisations manage short-lived certificates in certificate-based authentication?
- How should healthcare organisations manage legacy systems when they cannot be upgraded safely?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org