FAQ - Industry compliance changes affecting certificate issuance
General
Shorter certificate and validation lifetimes can reduce the risk of a compromised certificate by up to 99%. As computing power and automation continue to advance, the longer a certificate or validation remains valid, the greater the risk that it could be compromised or misused.
To address this, industry standards bodies and browser vendors are tightening requirements across the public trust ecosystem. These updates limit the impact of stolen keys, stale validations, and long-lived credentials, and they apply industry-wide to all Certification Authorities.
No. These requirements are mandated by industry standards and apply equally to all Certificate Authorities.
No. Existing certificates remain valid until their expiration date. These changes affect how certificates are issued and validated going forward.
Code Signing certificates
Code signing certificates are subject to:
- Shorter validity periods
- More frequent identity validation
- Stronger enforcement of organizational controls
- These changes are being phased in over time
Code signing certificates establish trust in software and updates. Long-lived credentials increase the risk of malware signing and supply-chain attacks if compromised.
No. Existing certificates remain valid until their expiration date (unless revoked).
What you need to do depends on how you use Code Signing certificates today.
If you use one-year Code Signing certificates:
If you use one-year Code Signing certificates, whether the keys are generated by Sectigo or on your own device, no action is required at this time. You can continue operating as you do today.
If you use multi-year Code Signing certificates:
If you rely on multi-year Code Signing certificates, you should begin preparing for upcoming changes to certificate validity and provisioning. We recommend the following steps:
- Review your certificate inventory and renewal strategy - Review your existing Code Signing certificates and renewal timelines now to avoid last-minute disruption as new requirements take effect.
- Place multi-year orders early (Sectigo-provisioned only) - If you require Sectigo-provisioned multi-year Code Signing certificates (where Sectigo generates the signing keys on a secure token), submit orders as early as possible and no later than February 15, 2026. After this date, this ordering option will no longer be available.
- Prepare for remote provisioning - Starting February 23, 2026, multi-year Code Signing certificates will be available only through remote provisioning.
- Remote provisioning means:
- You generate the signing keys on your own compliant device or token
- You provide a key attestation during the order process
- To prepare, ensure you have:
- A compliant token or device supported by Sectigo
- The ability to generate keys and provide key attestation during ordering
- Remote provisioning means:
- Plan for shorter certificate validity - Going forward:
- No Code Signing certificate will have a validity period longer than 459 days
- For multi-year products, the first certificate will be issued for 400 days to reduce revalidation effort
- Subsequent certificates will be issued for:
- 400 days, or
- The remaining time in the purchased product term, whichever is shorter
In cases where the remaining product term is more than 400 days but less than 459 days, the certificate will be issued for the remaining product term to minimize unnecessary revalidation.
Early renewal initiation is strongly recommended to avoid delays."
Software publishers, CI/CD teams, and organizations that rely on automated build and release pipelines should prepare early to avoid disruption.
These industry changes bring three key updates:
- Updated Validity Period
Sectigo Code Signing certificates will have a maximum validity of 459 days. This slight reduction ensures flexibility for various scenarios and compliance. - Early Enforcement of Changes
Sectigo will implement these changes ahead of the CA/B Forum deadline (see the timelines below). This proactive approach allows time to validate systems and processes, ensuring compliance when the official deadline arrives. - Certificate Product Offering Updates
- 1-year Code Signing certificates:
These will remain available for purchase, regardless of the delivery method – whether the keys are generated by Sectigo (our “Sectigo provisioning” solution) or by the customer remotely on their device (“remote provisioning”). - Multi-year Code Signing certificates:
- Going forward, multi-year certificates will only be offered through remote provisioning. This requires customers to use a compliant token or device supported by Sectigo and provide a key attestation from that device when placing an order, in line with CA/B Forum requirements.
- The multi-year Sectigo-provisioned Code Signing certificate option will be discontinued.
- 1-year Code Signing certificates:
We anticipate a significant increase in order volume, so implementing the change in two phases allows us to allocate time and resources to issue as many multi-year Sectigo-provisioned certificates as possible before the final enforcement date.
Once enforcement begins, Sectigo will no longer support issuing multi-year token-based Code Signing certificates, customers who need multi-year terms will need to use remote provisioning. That’s why we’re moving quickly now: to help token-based customers complete their multi-year orders and issuance before the cutoff and avoid disruption.
See our guide about supported key attestations on https://www.sectigo.com/knowledge-base/detail/Sectigo-Code-Signing-Certificate-Guides
DCV
The CA/Browser Forum has updated its requirements to shorten the maximum DCV reuse period. In alignment with this mandate, Sectigo will enforce the new DCV reuse limit starting March 12, 2026.
After this date, domain validations can only be reused for approximately six months, and any DCV beyond that period must be revalidated before it can be used to issue or reissue a certificate.
The CA/Browser Forum has updated its requirements to shorten the maximum period that Domain Control Validation (DCV) can be reused. In alignment with this mandate, Sectigo will enforce the new DCV reuse limit starting March 12, 2026.
After this date, domain validations can only be reused for approximately six months, and any DCV that exceeds the allowed reuse period must be revalidated before it can be used to issue or reissue a certificate.
Reducing DCV reuse limits the risk of relying on outdated domain ownership information and reduces the window of opportunity for attackers to exploit compromised or misconfigured domains. Shorter reuse periods help ensure certificates are issued based on current, verified domain control rather than historical validation data.
Yes. The reuse limit applies regardless of how DCV was originally performed.
DNSSEC (Domain Name System Security Extensions)
DNSSEC (Domain Name System Security Extensions) provides cryptographic assurance that DNS data has not been tampered with.
DNSSEC strengthens domain control validation and CAA lookup by ensuring DNS responses used during validation are authentic and trustworthy.
That said, DNSSEC improves security but it requires careful management. A DCV/CAA lookup that returns a SERVFAIL error, for instance, or any other error will likely result in issuance delays.
DNSSEC is not required.
It is recommended where supported to improve the integrity of your DNS data, especially as validation events occur more frequently under the new, shorter certificate lifetimes. However, domains that use DNSSEC must ensure their DNSSEC configuration is maintained correctly, as CAs are required to halt issuance if DNSSEC validation fails.
Client Authentication (EKU)
Publicly trusted SSL/TLS certificates are no longer intended to support Client Authentication (clientAuth EKU). As part of industry-wide changes, Sectigo has already removed this capability from standard certificate issuance.
- Today: Client Authentication is no longer included by default
- February 10, 2027: final deadline in which no public TLS certificates will include clientAuthentication under any circumstance
No. Most customers who use SSL/TLS certificates only for HTTPS website security (server authentication) are not affected.
This change primarily impacts organizations using certificates for:
- Mutual TLS (mTLS).
- Server-to-server authentication.
- Machine identity or client authentication workflows.
Certificates issued before the final enforcement deadline will continue to function until they expire or are revoked.
However:
- New, renewed, or reissued certificates will not include clientAuth by default
- After February 10, 2027, clientAuth will not be available in any newly issued public TLS certificates.
Yes, limited exceptions may be granted for enterprise customers who require additional time to transition.
- Exceptions must be approved with a valid business justification.
- Approved exceptions may allow issuance with clientAuth for a limited duration, up to a maximum of February 10, 2027.
- Exceptions are not available for retail (eCommerce) or certain customer segments.
Exceptions are intended to provide time for transition in cases where there's a clear objective need not a long-term solution.
If your organization relies on SSL/TLS certificates for client authentication, you will need to transition to an alternative solution.
We recommend moving these use cases to a Private Certificate Authority (Private CA), which provides:
- Greater control over certificate usage
- Support for client authentication
- Flexibility for internal and service-based trust models
No. Public TLS certificates will no longer support clientAuth moving forward.
- The capability is already deprecated in standard issuance
- After February 10, 2027, it will be fully removed
Organizations should transition affected use cases timely.
This change aligns with evolving browser and CA ecosystem requirements that aim to ensure publicly trusted certificates are used only for their intended purpose—server authentication for HTTPS.
It also reflects a broader industry shift toward clearer separation between:
- Public trust (web security)
- Private/internal trust (authentication use cases)
You may be impacted if you:
- Use mTLS between services or applications
- Rely on certificates for API authentication
- Use certificates for internal or partner-based authentication
If you are unsure, it is recommended to review your certificate usage and dependencies.
Best practices
We recommend beginning to prepare by:
- Reviewing your certificate and validation workflows to understand how these changes may affect your current approaches to certificate management and domain validation
- Identifying areas that rely on manual processes, which may become harder to sustain as lifecycles shorten
- Planning for more frequent certificate renewals and validations
- Considering automation where possible to reduce operational overhead and the risk of disruption
Taking these steps early can help ensure a smooth transition as the new requirements take effect.
Yes. The industry has signaled continued movement toward shorter certificate and validation lifecycles. Sectigo is building for this future now.
Sectigo will provide:
- Ongoing updates to this landing page
- Follow-up email communications
- Platform visibility enhancements
- Guidance and best practices
We’re here to help ensure a smooth transition as industry requirements evolve:
- Your Sectigo account representative
- Sectigo Support
TLS/SSL certificate lifetime changes
Public TLS/SSL certificates are moving toward shorter maximum lifetimes, beginning with a reduction to 199 days (approxiamtely 6 months) in 2026, with additional reductions planned in future phases.
Shorter lifetimes reduce the impact of compromised keys, and improve overall security posture across the web.
Shorter lifetimes mean:
- More frequent renewals
- More frequent DCV checks
- Greater importantce and reliance on automation
- Reduced tolerance for manual certificate management at scale
MPIC (Multi-Perspective Issuance Corroboration)
MPIC requires domain validation to be confirmed from multiple independent network perspectives before a certificate can be issued. This largely eliminates the risk that a compromised DNS provider will result in fraudulent certificate issuance
To find more information on MPIC, check out our MPIC FAQ page here
No. MPIC is enforced automatically by the Certificate Authority and does not require customer action if your DNS is not geofenced.
Partner
This page includes partner-relevant updates for TLS/SSL (shorter certificate lifespans and DCV reuse limits) and Code Signing (ordering/provisioning changes and validity limits). If you sell Code Signing, review the Code Signing section and share those requirements with your customers.
Tell customers that publicly trusted SSL/TLS certificates will now be issued with a maximum lifespan of approximately 6 months, so they’ll need to reissue and install certificates more frequently to avoid outages.
No. You can continue to sell 1–5 year TLS terms; what changes is the maximum validity of each issued certificate (now ~6 months). Communicate that the term stays the same, but the issued certificate lifespan is shorter, so customers should plan for more frequent reissuance during the term.
Nothing changes. Certificates issued before March 12, 2026 will remain valid until their scheduled expiration date, unless they are revoked for other reasons.
The upcoming changes apply only to certificates issued or reissued on or after March 12, 2026. Customers do not need to replace or modify certificates that are already in use.
Additional note for Code Signing:
- While previously issued Code Signing certificates are unaffected, partners should be aware that multi-year, Sectigo-provisioned Code Signing certificates will no longer be available for new orders after February 15, 2026. After this date, multi-year Code Signing certificates will be available only through remote provisioning.
Partners should plan accordingly when advising customers with upcoming Code Signing needs.
Customers will reissue more frequently during their purchased term to stay current, since each issued certificate is valid for up to 6 months. Customers will obtain a new certificate more often. Set expectations clearly: each issued certificate is valid for up to ~6 months, and reissuance becomes a normal part of staying current.
If less than 6 months remain in the purchased term, the issued certificate will only be valid for the remaining time (e.g., 30 days remaining will result in a 30-day cert).
No. Organization validation requirements are not changing due to this update.
DCV reuse is shortening to ~6 months; if a prior DCV is older than the allowed window, the customer will need to complete DCV again before issuance/reissuance.
Encourage customers to adopt automation wherever possible to handle faster reissuance cycles with less manual effort and lower outage risk. For customers doing this manually today, reinforce that the operational lift will increase without process changes.
Sectigo’s CaaS (Certificate as a Service) is built for this future state and helps reduce operational overhead for you and your customers. Learn more about CaaS here.
Direct them to the Compliance Update Hub as the ongoing source of truth. This keeps partner/customer messaging aligned and reduces back-and-forth when timelines and guidance are updated.