What should organisations do when certificate rotation is still mostly manual?

Treat manual rotation as a readiness gap and test shorter lifecycles in a controlled way to expose where automation, approval paths, or service dependencies will fail. Manual handling scales poorly when trust transitions accelerate. The immediate goal is to prove that renewal can be repeated safely before the environment has to absorb wider cryptographic change.

When manual certificate rotation stops being sustainable

Manual rotation is often acceptable only while the certificate estate is small, stable, and well understood. Once lifecycles shorten, renewals multiply, or certificates are embedded in services with fragile dependencies, the process becomes a reliability and change-management problem as much as a cryptographic one. The practical question is no longer whether people can rotate certificates, but whether the organisation can repeat the process without outages, exceptions, or hidden dependency failures.

That is why a controlled reduction in certificate lifetime is useful. It creates a realistic test of whether inventory, approval, deployment, rollback, and service discovery are good enough to support future trust transitions. When teams cannot complete the cycle cleanly at the current pace, they usually will not cope better when renewal windows compress further.

For organisations managing machine and service identities, the issue is not just certificate expiry but lifecycle control across dependent systems. NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide explains why shorter certificate validity pushes teams toward automation, ACME-style renewal, and clearer private key handling. The same readiness check also applies when certificate handling is only one part of a broader identity lifecycle, which is why the NHI Lifecycle Management Guide is useful for understanding where provisioning, rotation, and ownership break down.

Where manual handling fails first

Manual rotation usually fails at the boundaries: systems that were not discovered, certificates that were not owned, environments that do not share the same renewal path, and approval chains that take longer than the cryptoperiod. The technical problem is rarely just renewal. It is the dependency map underneath renewal, including application restarts, load balancers, embedded trust stores, and consumers that assume the old certificate will remain valid.

Credential and certificate sprawl also creates hidden concentration risk. A team may believe it is rotating one certificate, but the same private key pattern or issuing process may be reused across many services. The result is that one missed step can affect many workloads at once, which is why Guide to NHI Rotation Challenges is a useful reference for the dependency and scale issues that make “manual but manageable” quickly become fragile.

Shorter lifecycles are also an operational forcing function. Publicly trusted certificate ecosystems continue to move toward tighter validity expectations, so organisations need to treat manual rotation as a temporary condition rather than a steady state. For the standards context, CA/Browser Forum is the key baseline reference for public certificate issuance and revocation expectations.

What organisations should do next

The right response is to narrow the problem before trying to automate everything. Start with a small set of production-critical certificates, reduce their lifetime in a controlled pilot, and measure whether renewal completes without human escalation. That tells you whether your estate is ready for broader automation or whether you first need better inventory, ownership, or deployment hooks.

Use the pilot to expose the exact control points that need to change: who approves renewal, which systems consume the certificate, how secrets are stored, and whether rollback is possible if a renewal breaks trust. If the pilot requires repeated manual intervention, the issue is not the certificate itself but the surrounding operating model, which should be fixed before lifetimes are shortened further.

Where key lifecycle discipline is part of the problem, teams should align the work to NIST SP 800-57 Key Management so that renewal, cryptoperiod, and key protection are handled as a lifecycle, not an ad hoc task. If the organisation is already seeing certificate handling behave like a recurring identity governance problem, the Lifecycle Processes for Managing NHIs section provides a good model for making ownership, rotation, and offboarding repeatable.

Risk and Threat Considerations

Manual certificate rotation becomes risky when renewal depends on a few people remembering the right steps at the right time. The exposure is not only expiry. It is also missed revocation, stale trust paths, and the chance that a compromised or outdated certificate remains usable longer than intended.

Failure mechanism: Renewal breaks when ownership, approval, deployment, or dependent service updates are not repeatable enough to complete before expiry or trust changes.

Impact: Services can fail closed, fail open, or keep trusting material that should have been replaced, which creates outage risk, trust-boundary exposure, and avoidable emergency work.

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, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-57	Key Management	Certificate rotation depends on key lifecycle, cryptoperiods and renewal discipline.
Recommendation — Align renewal windows and key protection to an explicit lifecycle policy.
CIS Controls v8	CIS-5 — Account Management	Manual certificate handling is a lifecycle governance problem requiring ownership and revocation discipline.
Recommendation — Assign owners and revoke or rotate certificate access on a fixed schedule.
ISO/IEC 27001:2022	A.5.15 — Access control	Certificate rotation changes trust access and must be governed as a controlled access path.
Recommendation — Define and enforce access rules for certificate issuance, renewal and revocation.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication, and Access Control	Certificates are authentication material and need controlled lifecycle management.
Recommendation — Manage certificate authentication material through controlled provisioning, renewal and revocation.
OWASP Non-Human Identity Top 10	NHI-07 — Long-Lived Secrets	Manual rotation often leaves certificates valid too long, increasing exposure if handling slips.
Recommendation — Reduce certificate lifetime and automate renewal before validity windows expand exposure.

Practitioner Guidance

What to prioritise: Identify the certificates whose failure would cause the most service disruption, then test those first under a shortened lifecycle. The point is to learn where the process breaks before the environment forces a deadline-driven migration.

What to verify: Confirm that every certificate has a named owner, an executable renewal path, and a documented rollback option. If any of those three are missing, manual handling is already a control gap rather than a process preference.

Decision rule: If a renewal cannot be completed predictably without ad hoc intervention, treat it as evidence that the estate needs automation or redesign, not as evidence that the team simply needs more reminders.

Practitioner takeaway: Manual rotation is acceptable only as a transition state, and the safest next step is to prove repeatability on a small scale before shorter lifecycles make the current process fail under pressure.