Category: Certification and Accreditation
Certificate Validity Period
Also known as: Certificate Lifetime, Validity Period, Certificate Lifespan
Simply put
A certificate validity period is the window of time during which a digital certificate is considered trustworthy and can be relied upon as authentic. It runs from a defined start date and time to a defined end date and time, after which the certificate expires and is no longer trusted. Once expired, a certificate must typically be renewed or replaced to continue securing connections or identities.
Formal definition
The certificate validity period is the interval bounded by the certificate's notBefore and notAfter fields, during which the certificate is intended to be valid (per NIST CSRC). For publicly-trusted TLS certificates, the maximum permitted validity is governed by the CA/Browser Forum Baseline Requirements, which have historically capped validity at 398 days (roughly 13 months). Maximum lifetimes are being reduced over time; some certificate authorities (for example, Let's Encrypt) have signaled shorter lifetimes, and the trend toward shorter validity periods generally drives adoption of automated certificate issuance and renewal. Exact maximum durations depend on the applicable version of the Baseline Requirements and the certificate type, and are subject to change through phased schedules; practitioners should confirm current limits against the governing requirements in force. Note that the validity period defines only the intended trust window and does not by itself guarantee that a certificate has not been compromised or revoked before expiry.
Why it matters
The certificate validity period determines how long a digital certificate can be relied upon before it must be renewed or replaced. When a certificate expires unexpectedly, the systems that depend on it can fail to establish trusted connections, causing service outages, broken integrations, and loss of user confidence. Because the validity period defines only the intended trust window, it is a foundational input to any certificate lifecycle management process, and mismanaging it is a common and avoidable source of disruption.
Who it's relevant to
Security Engineers and Platform Teams
Engineers responsible for TLS termination, service-to-service authentication, and machine identities need to track validity periods to prevent expiry-related outages. As maximum lifetimes are reduced through phased schedules, shorter validity periods generally drive adoption of automated certificate issuance and renewal, which these teams typically own and operate.
Compliance and GRC Professionals
For SOC 2 engagements, certificate management practices may fall under the Security (Common Criteria) category and, depending on scope, the Availability criterion, since expired certificates can cause service disruption. For ISO 27001, certificate lifecycle handling may be addressed through relevant Annex A reference controls selected via the Statement of Applicability, depending on the organization's risk assessment and the version of the standard in use. In both cases, the applicability and depth of testing depend on the auditor, certification body, and defined scope.
Auditors and Assessors
Assessors reviewing cryptographic and PKI controls may examine how an organization tracks and renews certificates before expiry, and whether validity periods align with applicable requirements. A SOC 2 report attests only to the controls and period covered, and an ISO 27001 certificate covers only the defined scope of the ISMS; neither guarantees that a certificate has not been compromised or revoked before its expiry.
IT Operations and Infrastructure Managers
Operations teams that manage inventories of certificates across servers, load balancers, and internal systems rely on accurate visibility into validity periods to schedule renewals. As permitted lifetimes shorten under evolving Baseline Requirements, manual renewal becomes increasingly impractical, reinforcing the case for automated lifecycle management.
Inside Certificate Validity Period
Validity Period Definition
The span of time during which a certificate is considered valid, bounded by a 'notBefore' and 'notAfter' timestamp encoded in the certificate. Outside this window the certificate is treated as not-yet-valid or expired by relying parties.
Publicly-Trusted TLS Certificate Lifetime Limits
For publicly-trusted TLS server certificates, the CA/Browser Forum Baseline Requirements cap the maximum validity period. The current maximum is 398 days (the Baseline Requirements state validity MUST NOT exceed 398 days, with a SHOULD NOT exceed 397 days). Under the phased schedule in the Baseline Requirements, the maximum reduces to 200 days beginning 15 March 2026, to 100 days beginning 15 March 2027, and to 47 days beginning 15 March 2029.
Phased Reduction Schedule
Rather than a single change, the maximum lifetime steps down over time (200 days, then 100 days, then 47 days on the dates above). Each step applies to certificates issued on or after its effective date, so the applicable limit depends on the issuance date.
Certificate-Type Variation
Validity periods differ by certificate type and use. Publicly-trusted TLS certificates are governed by the Baseline Requirements, while internal/private CA certificates, code-signing certificates, and root/intermediate CA certificates commonly follow different lifetimes set by policy or the issuing authority.
Relationship to Renewal and Rotation
Shorter validity periods increase the frequency of certificate renewal and rotation, which is a driver for automated issuance and lifecycle management. The validity period defines when replacement must occur to avoid expiry-related outages.
Relevance to Compliance Evidence
In SOC 2 examinations and ISO/IEC 27001 assessments, certificate validity periods can be evidence supporting controls over encryption in transit, key/certificate lifecycle management, and change management. How this is evaluated depends on the auditor, certification body, scope, and applicable criteria.
Common questions
Answers to the questions practitioners most commonly ask about Certificate Validity Period.
Does an ISO 27001 certificate or a SOC 2 report have a fixed expiration date I can rely on indefinitely once issued?
No. These two outcomes behave very differently, and neither should be treated as an open-ended guarantee. An ISO/IEC 27001 certificate, issued by an accredited certification body, is typically valid for a defined cycle subject to ongoing surveillance activities and eventual recertification; the certificate covers only the defined scope of the ISMS for that period and can be suspended or withdrawn if the management system is found to be nonconforming. A SOC 2 report is not a certificate at all, it is an attestation examination performed by a licensed CPA firm under SSAE 18, and it speaks only to the controls and, for a Type II, the review period covered. Once that period ends, the report does not 'expire' so much as become progressively less current, which is why report consumers commonly request a fresh report on a recurring basis.
If a certificate or report is currently 'valid', does that mean the organization is free from breaches or gaps for the whole validity window?
No, and this is a common misreading. A SOC 2 report attests only to the suitability of design (Type I) or the design and operating effectiveness (Type II) of the controls in scope over the stated period; it does not guarantee freedom from breaches, nor does it cover controls or time outside the defined scope. Similarly, an ISO 27001 certificate confirms conformity of the ISMS within its defined scope at the assessment points, not that no incident can occur. Validity indicates that the framework's requirements were met as assessed, not that risk has been eliminated. Reviewers should always confirm what scope and period the document actually covers rather than assuming blanket assurance.
How should I determine the review period for a SOC 2 Type II when planning our examination timing?
The review period is a scoping decision made with your service auditor rather than a fixed duration set by the standard. A Type II assesses both design and operating effectiveness over a defined period, and the length of that period varies by engagement. In most engagements organizations coordinate with the CPA firm to select a period that balances stakeholder expectations, the maturity of the controls, and the timing of prior reports so that successive reports provide continuous coverage without gaps.
What should we do to maintain continuous coverage between one SOC 2 report and the next?
Because a SOC 2 report speaks only to the period it covers, many organizations plan successive Type II periods so that the end of one period aligns with the start of the next, avoiding coverage gaps that report consumers may question. When a gap does occur, some auditors can provide a bridge or gap letter describing whether material changes occurred, though the availability and content of such letters depend on the CPA firm. Planning the next examination well before the current period ends is the typical approach to avoid lapses in the assurance you can provide to customers.
What activities keep an ISO 27001 certificate in good standing during its cycle?
Maintaining an ISO 27001 certificate typically involves ongoing surveillance activities conducted by the certification body during the certification cycle, followed by a recertification assessment before the cycle ends. Throughout, the organization is expected to operate and continually improve its ISMS in line with the requirements in clauses 4 through 10, keep its risk assessment and Statement of Applicability current, and address any nonconformities raised. The exact schedule and expectations are set by the accredited certification body, so organizations should confirm the specifics with their chosen body rather than assuming a universal timetable.
Can we reuse the validity of one framework to satisfy the other's timing or renewal requirements?
Not directly. Mapping between SOC 2 and ISO 27001 is possible but partial, and satisfying one does not automatically satisfy the other. The two also operate on different lifecycles: a SOC 2 report covers a point in time or a defined review period, while an ISO 27001 certificate follows a certification and surveillance cycle managed by a certification body. Organizations pursuing both should plan each timeline independently, even where shared evidence and controls reduce duplicated effort, because the renewal and validity mechanics are governed by different bodies and standards.
Common misconceptions
The maximum publicly-trusted TLS certificate lifetime drops directly from 398 days to 47 days on 15 March 2026.
The reduction is phased under the CA/Browser Forum Baseline Requirements: a 200-day limit begins 15 March 2026, a 100-day limit begins 15 March 2027, and the 47-day limit begins 15 March 2029. There is no single-step jump to 47 days in 2026.
A valid, unexpired certificate proves a system is secure or compliant.
A validity period only defines the time window in which a certificate is accepted by relying parties. It does not by itself demonstrate secure configuration, sound key management, or compliance; a SOC 2 report attests only to the controls and period covered, and an ISO 27001 certificate covers only the defined ISMS scope.
All certificates follow the same validity limits as publicly-trusted TLS certificates.
The Baseline Requirements limits apply to publicly-trusted TLS certificates. Private/internal CA certificates, code-signing certificates, and CA (root/intermediate) certificates typically follow different lifetimes governed by their own policies rather than the TLS server certificate schedule.
Best practices
Track the phased Baseline Requirements schedule (398-day current maximum, then 200 days from 15 March 2026, 100 days from 15 March 2027, and 47 days from 15 March 2029) and plan renewal cadences against the limit that applies to each certificate's issuance date.
Adopt automated certificate issuance and renewal so that shorter validity periods do not translate into manual toil or expiry-related outages, since renewal frequency rises as maximum lifetimes decrease.
Maintain an inventory of certificates with their notBefore/notAfter dates, issuing authority, and certificate type, distinguishing publicly-trusted TLS certificates from internal CA, code-signing, and root/intermediate certificates that follow different lifetimes.
Implement expiry monitoring and alerting with sufficient lead time before the notAfter date to allow rotation before relying parties reject the certificate.
Retain certificate lifecycle records (issuance, renewal, revocation) as evidence for encryption-in-transit and change-management controls, recognizing that how such evidence is assessed varies by auditor, certification body, scope, and applicable criteria.
Do not treat an unexpired certificate as evidence of overall security or compliance; document validity-period management as one control among the broader set required by the applicable SOC 2 criteria or ISO 27001 ISMS scope.