Should organisations prioritize short-lived certificates before replacing VPNs and bastions?

Why This Matters for Security Teams

Replacing VPNs and bastions without first changing how credentials work usually preserves the same durable trust problem in a new wrapper. Short-lived certificates reduce the blast radius of exposure because access is time-bound, resource-specific, and easier to revoke. That matters in NHI-heavy environments where machine identities already outnumber human identities at scale, and where manual handling still leaves too much room for drift, stale access, and silent misuse. Ultimate Guide to NHIs — What are Non-Human Identities is the best starting point for the lifecycle risks behind that problem, while NIST Cybersecurity Framework 2.0 reinforces the need to reduce access exposure, not just relocate it.

The practical reason to prioritise certificates first is that VPNs and bastions are network controls, but compromise often happens through identity abuse, not network traversal alone. If long-lived credentials remain valid, a hardened perimeter can still be bypassed through stolen secrets, over-privileged service accounts, or unattended automation. Short-lived certificates, by contrast, create a natural forcing function for lifecycle governance, rotation, and tighter issuance rules. In practice, many security teams encounter credential reuse and lingering access only after an incident has already occurred, rather than through intentional control design.

How It Works in Practice

A workable sequence is to treat short-lived certificates as the identity control layer that makes network simplification safe. Start by inventorying where machines authenticate, then replace static secrets and persistent trust links with certificate issuance tied to workload identity, ideally backed by policy checks at request time. Current guidance suggests pairing this with Ultimate Guide to NHIs — What are Non-Human Identities style lifecycle thinking: define owners, rotation thresholds, revocation paths, and service-specific scope before any perimeter decommissioning.

That sequence matters because a certificate is only helpful if issuance is constrained and revocation is operationally real. In mature environments, teams often combine short-lived certificates with PAM for administrative paths, RBAC for coarse-grained entitlements, and ZTA principles for continuous verification. The stronger pattern is to issue credentials JIT, bind them to workload identity, and expire them quickly enough that stolen material loses value before it can be reused. For architectural direction, NIST Cybersecurity Framework 2.0 is useful for mapping governance, protection, and recovery tasks across this transition.

• Use short-lived certificates for service-to-service access before shrinking VPN reach.
• Issue credentials only after workload identity and ownership are validated.
• Set revocation and renewal to run automatically, not by ticket.
• Keep bastions only where human break-glass access still has a clear operational need.

That is especially important when secrets are embedded in CI/CD, configuration files, or automation scripts, because certificate rollout can fail if the old paths remain equally convenient. Sisense breach is a reminder that identity material exposed in tooling or automation can become an enterprise incident even when the network looks segmented. These controls tend to break down when legacy applications require fixed endpoints and long-lived mutual trust, because the application cannot yet consume short-lived credentials cleanly.

Common Variations and Edge Cases

Tighter certificate controls often increase operational overhead at first, so organisations have to balance the security gain against rollout complexity, application compatibility, and support burden. That is why the best practice is evolving rather than universal: not every environment can retire VPNs and bastions immediately, and some regulated or vendor-managed workloads still need transitional access paths.

One common exception is brownfield infrastructure with hard-coded trust stores or appliances that cannot rotate certificates quickly. In those cases, current guidance suggests isolating the legacy segment, limiting standing access, and using certificates only where expiry, renewal, and revocation can be enforced consistently. Another edge case is high-availability admin access, where bastions still have a role as audited break-glass points. Even there, the point is to make bastions exceptional, not central.

For teams running large fleets, the strongest signal is whether certificates are tied to real lifecycle controls. If ownership is unclear, revocation is manual, or workload identity is not established, short-lived certificates become another layer of friction rather than a control improvement. The main tradeoff is clear: faster expiry reduces exposure, but only if automation, inventory, and policy enforcement are mature enough to keep critical services online. In mixed estates, that maturity gap is often what slows down perimeter retirement more than the network design itself.

Related resources from NHI Mgmt Group

• When does a short-lived API key still create material risk?
• What is the difference between short-lived tokens and static API keys for agents?
• When does a short-lived credential still become a long-term risk?
• What is the most common mistake organisations make with NHI credential management?