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.
eIDAS QWAC certificates — RSA key size requirements
Beginning November 30, 2026, new RSA-based eIDAS QWAC certificate requests, including PSD2 QWACs, must use an RSA key of at least 3072 bits.
Beginning December 15, 2026, Sectigo will no longer issue RSA-based eIDAS QWAC certificates using RSA keys smaller than 3072 bits.
The change aligns Sectigo's issuance practices with evolving cryptographic standards and supervisory requirements applicable to qualified trust services.
The requirement applies to RSA-based eIDAS QWAC certificates, including PSD2 QWAC certificates.
It applies to new certificate requests, renewals, replacements, and reissues.
The change is being introduced in two stages:
- November 30, 2026: New RSA-based eIDAS QWAC certificate requests must use RSA keys of at least 3072 bits. Requests using smaller keys may require a new Certificate Signing Request (CSR) before issuance can proceed.
- December 15, 2026: Sectigo will no longer issue RSA-based eIDAS QWAC certificates using RSA keys smaller than 3072 bits.
Customers should update their certificate request processes before November 30 to help avoid issuance delays.
No. Existing certificates remain valid until their expiration date unless otherwise communicated.
The new RSA key size requirement applies when requesting a new certificate, renewal, replacement, or reissue after the applicable implementation dates.
No. This requirement applies specifically to RSA-based certificates. Customers using Elliptic Curve Cryptography (ECC) keys are not affected by this RSA key size requirement.
Review any systems, tooling, or automation used to generate Certificate Signing Requests (CSRs) for eIDAS QWAC and PSD2 QWAC certificates.
If those processes currently generate RSA keys smaller than 3072 bits, update them to generate RSA keys of at least 3072 bits before November 30, 2026.
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.
RSA Key Size Requirements — PSD2 QWAC — Trust changes
Effective September 30, 2026, newly issued PSD2 QWAC certificates will no longer be trusted by Google Chrome or Mozilla/NSS.
Existing certificates are not affected by this change.
PSD2 QWAC certificates are intended for PSD2 and Open Banking ecosystems, where they support authenticated and trusted communications between regulated payment service providers.
They are not intended to secure public websites or provide browser trust.
In time, PSD2 QWAC certificate issuance will be migrated to a hierarchy only in scope of the EU Trusted List (EUTL).
No. The September 30 change applies to newly issued PSD2 QWAC certificates. Existing certificates are not affected by this change.
PSD2 QWAC certificates are intended for PSD2 and Open Banking use cases and are not intended for public website authentication or browser trust.
If your organization currently uses a PSD2 QWAC certificate to secure a publicly accessible website, you should begin planning to migrate that use case to a standard eIDAS QWAC certificate (non-PSD2) for public website authentication.
If you use eIDAS QWAC or PSD2 QWAC certificates, take two actions:
- PSD2 QWAC: Before September 30, review where your PSD2 QWAC certificates are deployed. If they are being used for public website authentication, plan to migrate those use cases to a standard eIDAS QWAC certificate (non-PSD2).
- RSA key size: Before November 30, ensure systems, tooling, and automation generating RSA-based QWAC certificate requests support RSA keys of at least 3072 bits.
Preparing in advance can help prevent certificate issuance delays and unexpected impacts to browser trust.
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.