Digital certificates, issued by an internal, private Certification Authority (CA) like Microsoft Active Directory Certificate Services (AD CS), are commonly used in enterprise environments for user and device authentication for workloads such as VPN, Wi-Fi (802.1x), System Center Configuration Manager (SCCM), IPsec, and more. But how long should a user or device authentication certificate be valid? This question is increasingly critical as organizations strive to balance security and operational efficiency. Short-lived certificates, typically valid for weeks or months rather than years, are gaining traction as a powerful tool to enhance security. By reducing the window of opportunity for attackers to exploit compromised credentials, short-lived certificates offer a proactive approach to mitigating risks while aligning with evolving security best practices and the needs of modern IT infrastructures.
What is a Certificate?
A digital certificate is a document that binds an identity to an asymmetric key pair (public key and private key). Certificates offer strong, phishing-resistant authentication that improves security and assurance for users and devices authenticating to Microsoft Active Directory (AD). When a certificate is issued, an administrator decides how long the certificate will be valid. The criticality of this setting is often overlooked.
Certificate Lifetime
Administrators must define the certificate’s validity period when creating a certificate template in AD CS or an Intune PKCS or SCEP device configuration policy. Most commonly, administrators select the default one-year validity period. However, public CAs are trending toward shorter certificate lifetimes, and strong consideration should be given to their use in private enterprise deployments.
Current Standards
Today, the maximum certificate lifetime for a publicly issued TLS certificate is 398 days (approximately 13 months). This standard is imposed by the CA/Browser Forum, a voluntary consortium of public CAs, browser vendors, and other industry stakeholders that develop and promote security standards and best practices for digital certificates and Public Key Infrastructure (PKI). They established the 398-day certificate lifetime mainly in response to the previous decade’s plethora of SSL/TLS vulnerabilities.
Challenges
Having certificates with long lifetimes poses significant challenges for administrators when responding to key compromise events or zero-day vulnerabilities. This may necessitate urgent certificate replacement, often involving manual intervention. To address these challenges and promote automation, some public CAs like Let’s Encrypt issue certificates with much shorter lifetimes than one year.
Public CA Certificates
Shorter lifetimes for public SSL/TLS certificates have numerous positive security benefits. Short-lived certificates provide agility to update cryptography settings more rapidly than long-lived certificates. Also, the short lifetime of the certificate is beneficial if the private key is compromised because it limits the amount of time an attacker can exploit the stolen key, limiting exposure and reducing potential damage. These security benefits have driven significant changes in public CA practices, as seen in today’s standards.
47 Days
Recently, I wrote about a new directive from the CA/Browser Forum, which adopted a measure reducing the current maximum lifetime of public TLS certificates to 47 days. The maximum lifetime for public TLS certificates will be gradually reduced to allow the industry to adopt short-lived certificates.
Enterprise CA Certificates
Private enterprise PKI deployments like AD CS are not required to adhere to CA/Browser Forum mandates. Organizations are free to manage their internal PKI however they choose. However, examining industry trends and ensuring that security best practices are aligned as much as possible is crucial. While public CAs set the pace, private enterprise PKI can adopt similar strategies to bolster security.
AD Authentication
As stated previously, many positive security benefits are associated with short-lived certificates, especially for authentication to Active Directory.
PKINIT
PKINIT is an extension to the Kerberos protocol that enables certificate-based authentication with Active Directory (AD). You can read about the details here, but PKINIT allows a principal (user or device) to authenticate to AD by simply demonstrating control of the private key. Thus, protecting the private key is vital.
TPM
Enrolling certificates in a Trusted Platform Module (TPM) is the best way to ensure private keys remain private. No one, including administrators, can export private keys protected by TPM. Administrators should ensure TPM enrollment for client authentication certificates whenever possible.
Guidance
Today, I recommend that my customers issue end entity user and device authentication certificates with a lifetime of no more than one year for 2048-bit RSA certificates with private keys stored on TPM. However, there are important considerations and compelling advantages to using much shorter lifetime certificates.
Best Practice
General use client authentication certificates should be enrolled to TPM without exception and have a valid lifetime of no more than one year. However, there is still value in using shorter lifetime certificates, even with TPM. For example, short-lived certificates ensure timely renewal, which can be helpful when implementing changes to certificate templates. A perfect example of this is the changes required to support KB5014754. Administrators may wish to use certificates with validity periods of less than one year to ensure timely replication of certificate settings changes and to provide more frequent key rotation.
Non-TPM
There may be scenarios where a client authentication certificate must be issued to a device without a TPM. Examples include virtual machines without TPM, VDI deployments, and legacy devices. These cases should be treated as exceptions and managed accordingly. Consider shortening the lifetime of non-TPM certificates to 90 days or less.
Privileged Users
Administrators or other privileged accounts enrolling for certificates can benefit from even shorter validity periods. Consider issuing client authentication certificates to these users with certificate lifetimes of 30 days or less.
Considerations
Short-lived certificates aren’t always ideal in all cases. For example, consider a scenario where a user or device is offline for a prolonged period, such as extended vacations, maternity or paternity leave, or sabbaticals. Users may experience issues accessing resources after returning from an extended absence. Of course, if they can re-enroll for certificates, this shouldn’t be a problem. For AD CS, it means connectivity to an enterprise issuing CA server. Intune-managed endpoints simply need Internet access to obtain a new certificate.
Automation
Working with short-lived certificates manually is infeasible. Automation is the key to success with short-lived certificates. For client authentication certificates issued on-premises, enabling certificate autoenrollment via group policy ensures that all domain-joined devices enroll and renew their certificates automatically. Certificates deployed and managed using Microsoft Intune are automated by default.
Summary
The next time you create a certificate template in AD CS or Intune, consider the certificate lifetime. Recommended best practice is no more than one year validity period for 2048-bit RSA end-entity certificates with hardware-backed key storage. However, consider shorter validity periods for those cases where it makes sense. Prioritize TPM enrollment and put additional controls in place for exceptions. Ensure automated enrollment and renewal are in place to reduce administrative overhead. Following the guidance outlined above, your organization will reduce its attack surface and limit exposure to compromised certificates.
More Information
If you’d like to learn more about implementing short-lived certificates in your organization, fill out the form below, and I’ll provide more information.
References
Digital Certificates for Strong Authentication
Drawbacks of Multifactor Authentication
Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol
