Subscribe to the Non-Human & AI Identity Journal

What do teams get wrong about 90-day certificate policies?

They often treat the new validity period as the control, when the real control is the renewal process behind it. A 90-day certificate policy fails if inventory is incomplete, exceptions are undocumented, or legacy systems cannot renew automatically. The policy only works when lifecycle ownership and telemetry are already in place.

Why This Matters for Security Teams

A 90-day certificate policy is often sold as a simple way to reduce exposure, but the date on the certificate is not the control. The control is the lifecycle behind it: discovery, ownership, issuance, renewal, revocation, and telemetry. NIST’s Cybersecurity Framework 2.0 treats asset visibility and continuous risk management as operational requirements, not paperwork.

That matters because certificate expiry is still a leading outage driver, and machine identities are rarely managed with the same discipline as human accounts. NHIMG’s Lifecycle Processes for Managing NHIs shows that lifecycle failures usually start with incomplete inventory, unclear ownership, and weak offboarding. Teams that shorten validity without fixing those basics often increase operational risk while believing they have improved security. In practice, many security teams discover renewal gaps only after a certificate has already expired and taken a service down.

How It Works in Practice

The effective way to run a 90-day certificate policy is to treat it as a renewal automation program, not a compliance deadline. That means every certificate must be tied to a known owner, a known service, and a known renewal path. If any of those are missing, the policy is brittle. Current guidance suggests using continuous inventory, automated issuance, and event-driven renewal rather than relying on manual reminders or spreadsheet tracking.

Practitioners usually need four capabilities:

  • Complete discovery of certificates across applications, clusters, CI/CD, and embedded devices.
  • Ownership mapping so each certificate has a accountable service or team.
  • Automated renewal and deployment before expiry, with fallback procedures for failed renewals.
  • Telemetry for expiry, failure rates, and exceptions so gaps are visible early.

This is where machine identity governance intersects with broader NHI controls. NHIMG’s What are Non-Human Identities research highlights that machine identities often outnumber human identities and are more difficult to audit. That is why a certificate policy must be paired with identity inventory and renewal orchestration. For implementation detail, NIST CSF 2.0 and the Top 10 NHI Issues both point to lifecycle visibility as the control that makes short validity periods workable.

Where teams often miss the mark is assuming every system can renew automatically. Legacy appliances, embedded systems, and cross-domain dependencies frequently cannot, and those environments need compensating controls, exception tracking, and migration plans. These controls tend to break down when certificates are embedded in legacy platforms with no API-based renewal path because the renewal step cannot be operationalized reliably.

Common Variations and Edge Cases

Tighter certificate rotation often increases operational overhead, requiring organisations to balance reduced exposure against renewal complexity and service stability. That tradeoff is especially visible in hybrid estates, third-party integrations, and devices that do not support modern automation. There is no universal standard for this yet, so teams should document exception handling instead of pretending every workload can meet the same renewal pattern.

One common edge case is long-lived service infrastructure that depends on vendor-managed or embedded certificates. Another is regulated environments where change windows are narrow, making automated rotation harder to schedule. In those situations, the right answer is not to ignore the 90-day target, but to define a controlled exception, shorten exposure wherever renewal is possible, and create a migration path toward automated lifecycle management.

NHIMG’s Critical Gaps in Machine Identity Management report notes that only 38% of organisations have automated certificate lifecycle management in place, which explains why so many 90-day policies fail at execution rather than design. Teams that rely on calendar-based renewal will usually miss the systems that most need protection. The policy works only when inventory, ownership, telemetry, and automation mature together.

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 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-03 Short cert validity still fails if rotation and renewal are not automated.
NIST CSF 2.0 ID.AM-1 Certificate policy depends on complete asset and identity inventory.
NIST AI RMF Lifecycle risk management maps to continuous governance and monitoring.
NIST Zero Trust (SP 800-207) 3.4 Certificate renewal is part of continuous trust evaluation in zero trust architectures.

Use AI RMF governance principles to ensure renewal controls are monitored, owned, and reviewed.