Sectigo Reports 38% Have Fully Assessed Their Quantum Exposure, but Only 4% Say Their Certificate Management Is Fully Automated

October 28, 2026 – Sectigo, a certificate authority (CA) and certificate lifecycle management (CLM) vendor based in Scottsdale, Arizona, today released its 2026 State of Crypto Agility Report, a survey of 500 senior IT and cybersecurity decision-makers on post-quantum cryptography (PQC), shorter TLS certificate lifespans and identities for AI agents. Seventy-eight percent of respondents said today’s public key infrastructure (PKI) will need major structural changes to support PQC.

Thirty-eight percent said their organization had fully assessed its systems for vulnerability to quantum attacks, up from 14% in the 2025 edition. Asked whether they planned to increase certificate automation because of shorter lifespans, 4% said their certificate management was already fully automated. Under CA/Browser Forum Ballot SC-081v3, adopted in April 2025, publicly trusted TLS certificates issued from March 15, 2027, can be valid for at most 100 days, down from 200.

Censuswide, a research firm, collected the responses between July 2 and July 21, 2026. Respondents held C-suite, vice-president or director roles in IT, technical operations, cybersecurity and risk, and were based in North America, Europe, the Middle East and Africa (EMEA) and Asia-Pacific (APAC). The APAC respondents included participants from India, Australia, New Zealand and Singapore. Omdia ran the survey behind Sectigo’s 2025 report, collecting 272 responses in the United States and EMEA in June 2025. In its methodology note, Sectigo says the two samples are not strictly like for like and that year-over-year comparisons should be read as directional.

PQC and PKI Findings

On quantum readiness, respondents reported:

• 38% had fully assessed systems vulnerable to quantum attacks, 44% said their assessment was mostly complete and 14% had completed a partial assessment. The remaining 4% planned to start one within 12 months.
• 83% had budget allocated to quantum-safe initiatives over the next year. Of those, 93% expected PQC investment to rise over the next two to three years, including 40% who expected an increase of 5% or more.
• 63% were extremely or very concerned about harvest now, decrypt later (HNDL) attacks, 60% about trust now, forge later (TNFL) attacks and 66% about man-in-the-middle attacks.
• 28% were extremely confident their current systems could integrate PQC without major disruption, up from 15% in 2025. Another 46% were very confident.
• 70% had known before the survey that Google had set 2029 as its PQC migration target.

Sectigo gives a section of the report to Merkle Tree Certificates (MTCs), a certificate format under development in the Internet Engineering Task Force’s PKI, Logs, And Tree Signatures (PLANTS) working group. In an MTC system, a CA records every certificate it issues in a public, append-only log organized as a Merkle tree. In the optimized form Sectigo describes, a website presents a short proof of inclusion, and the browser checks it against log data received earlier through software updates. Sectigo puts a single ML-DSA (formerly CRYSTALS-Dilithium) signature at roughly 2.4 kilobytes and a Merkle inclusion proof at typically under one kilobyte. The company also says in the report that it contributed to the approach, which cryptographers at Google and Cloudflare have been developing.

Among respondents familiar with MTCs, 40% said their organization was very clear on the changes its systems, processes and environments would need, and another 40% said fairly clear. Sectigo does not say how many of the 500 respondents were familiar with MTCs.

In its timeline section, Sectigo cites NIST’s transition plan and Executive Order 14412, which President Trump signed in June. In the order, he directed the Office of Management and Budget (OMB) to issue guidance requiring federal agencies to move key establishment in their high value assets and high-impact systems to PQC by December 31, 2030. Under the same guidance, agencies must move digital signatures in those systems by December 31, 2031. Sectigo also cites the 2029 migration targets that Google announced in March and Cloudflare in April.

Certificate Lifespan Findings

Under SC-081v3, publicly trusted TLS certificates issued from March 15, 2026, can be valid for at most 200 days, down from 398. For certificates issued from March 15, 2027, the maximum is 100 days. From March 15, 2029, it is 47 days, and a CA can reuse a domain control validation (DCV) for only 10 days. Respondents reported:

• 62% had a complete, up-to-date inventory of their public SSL/TLS certificates, up from 28%.
• 33% were extremely confident they track all their certificates, including rogue ones, up from 13%. Another 48% were very confident.
• 61% had experienced a certificate-related outage or incident in the previous 12 months.
• 40% described themselves as very prepared for monthly renewals because they already have automated systems in place, up from 19%.
• 61% were very or extremely concerned about the impact of 47-day certificates, up from 52%.
• 73% planned to increase certificate automation because of shorter lifespans.
• 96% saw at least some overlap between preparing for 47-day certificates and preparing for PQC, including 18% who said the two were exactly the same.

Sectigo reported automation gains for provisioning (40%, from 32%), deployment (42%, from 33%), revocation (37%, from 27%) and DCV (42%, from 32%). In the 2026 report, Sectigo does not say how it calculated these figures. In the 2025 report, the equivalent figures were averages of the share of certificates respondents had automated for each task. Sectigo writes that certificate renewals “remain the most automated certificate management task” but does not give a 2026 figure for renewal.

Agentic AI and the Risk Ranking

Sixty-five percent of respondents were extremely or very concerned about attacks on agentic AI systems that use identity spoofing, impersonation or misuse of digital credentials. Asked to rank three challenges by the risk each poses to their organization, 45% put quantum threats first, 28% shorter certificate lifespans and 27% identity for agentic AI.

“PQC is not simply an algorithm swap, and shorter certificate lifespans are not simply a renewal problem,” Nick France, Sectigo’s chief technology officer, said in the announcement. Sectigo will present the findings in a webinar on November 17.

My Analysis

Sectigo is one of the largest public certificate authorities, with more than 700,000 customers by its own count. It also sells the certificate lifecycle software it recommends in the report. Nick France was one of three endorsers of the 47-day ballot, which Apple proposed and Sectigo voted for.

Sectigo published the answer distribution for all 18 questions in an appendix. I used it to check the headline figures and to estimate one figure Sectigo left out.

The number I would put in front of a board is the 4%. With less than five months to go before newly issued public certificates are limited to 100 days, 4% of respondents chose “already fully automated” when asked about their plans for certificate automation. The other 96% still have people doing some of their certificate work. From March 15, 2027, those people will repeat that work twice as often for each certificate issued at the maximum lifetime.

The 2025 and 2026 Samples Differ in Research Firm, Size and Region

Between the 2025 and 2026 editions, Sectigo changed research firm from Omdia to Censuswide, increased the sample from 272 to 500 and added APAC respondents. In the 2025 foreword, Sectigo described its respondents as coming from medium to large enterprises, and on its podcast about the 2025 results, Tim Callan, Sectigo’s chief compliance officer, put the floor at 1,000 employees. Sectigo gives no size floor in the 2026 methodology and says in neither report how it weighted the responses. With a different panel, a percentage can change even if no organization has changed, and I found no way to separate the two effects in the published data. Some of the 24-point rise in full quantum assessments may be real, but I can’t tell from the report how much.

Sectigo makes year-over-year comparisons in its release and report only for measures that rose. In his foreword to the 2026 report, France writes that more organizations are “allocating budget to quantum-safe initiatives.” On the same question in both years, the share of respondents with budget fell from 90% to 83%. Sectigo also left renewal automation, which it reported at an average of 53% of certificates in 2025, out of the 2026 comparison.

If renewal remains the most automated task, as Sectigo writes, its 2026 average is at least 42%, the highest figure Sectigo published for the other tasks. Using the midpoint of each answer band in the appendix, I get about 42% for renewal. Applying the same method to the four tasks Sectigo did publish, I get within three points of Sectigo’s numbers, so I take the 2026 figures to be averages, as in 2025. My estimates come from rounded, grouped answers. If I place every answer at the bottom or the top of its band, the renewal estimate ranges from about 38% to 47%. Taking Sectigo’s statement into account, I put the 2026 renewal average between 42% and 47%, six to 11 points below the 53% of 2025. The share saying they were already fully automated went from 5% to 4%. I would read the declines with the same caution as the rises, since both compare the same two samples.

In the appendix, Sectigo reports 0% for several answers I would have expected a few organizations to choose: “not planning to at all” and “don’t know” on the quantum assessment question, “we rely on manual tracking or informal methods” on public certificate tracking, and “not prepared” on monthly renewals. Sectigo rounds to whole percentages, so a few of the 500 respondents could still have chosen an answer shown as 0%. Sectigo doesn’t describe how Censuswide recruited or screened respondents, so I can’t tell why the bottom of each scale is nearly empty. I read the results as a benchmark for organizations already working on certificates and PQC, and as a weaker guide to the market as a whole.

Self-Reported Quantum Assessments Compared With GAO’s Inventory Audit

Sectigo asked whether respondents’ organizations had “conducted an assessment of systems vulnerable to quantum computing attacks” and offered “fully,” “mostly” and “partially” without defining what an assessment covers. Each respondent applied their own definition. Ninety-six percent said they had done at least a partial assessment, and 82% said fully or mostly.

Two other surveys published this year asked related questions. DigiCert surveyed 1,001 respondents in the US, UK and Australia in May and found that 50% had conducted quantum risk assessments and 44% had created cryptographic inventories. The Hong Kong Monetary Authority surveyed the banks it supervises and found that 66% of respondents had not assessed their quantum-related exposure.

The US Government Accountability Office (GAO) checked evidence. In an audit run from February 2024 to September 2025 and published on October 6, GAO compared each of 24 federal agencies’ inventories of quantum-vulnerable cryptography with the agency’s own lists of high value assets and high-impact systems. One agency’s inventory of its priority systems passed all of GAO’s completeness checks. GAO then selected six agencies and asked for documents supporting the algorithms listed for sampled systems. One of the six had no inventory to sample. None of the other five could document the algorithms for every system GAO checked, and three could document none.

Sectigo, DigiCert, the HKMA and GAO studied separate populations, worded their questions in their own ways and accepted varying standards of evidence, so I can’t rank their results on one scale. With its audit, GAO showed why a supervisor should not accept an inventory as complete or accurate without the evidence behind it. For years I have argued that organizations, and the regulators asking for cryptographic inventories, underestimate the work. I have also seen many inventories assembled from interviews with system owners, without discovery tools.

The 62% who report a complete inventory of public TLS certificates have done the most accessible inventory in the estate. Google and Apple require publicly trusted TLS server certificates to be logged in Certificate Transparency (CT) before Chrome and Apple’s operating systems will accept them, so an organization can find the public certificates issued for its domains by searching the logs. To learn where each one is deployed, who owns it and whether it is still in use, the organization has to reconcile the logs with its own endpoint and key-management records. For quantum exposure, an organization also has to inventory its private PKI, SSH keys, VPNs, encrypted stored data, code signing and vendor products, none of which it can discover through CT logs.

Eighty-one percent of respondents were extremely or very confident they track every certificate, and 61% had a certificate-related outage or incident in the previous 12 months. I don’t read the two answers as contradictory. Some incidents may predate the improvement, and some respondents may have tightened their tracking after an outage. Sectigo notes that an organization can still have an outage after renewing a certificate if nobody deploys it to the correct endpoint, if an application reload fails, if someone mishandles the private key, or if nobody completes a manual validation step on time. In the appendix, 31% of respondents say they automate the deployment of more than half of their certificates.

Certificate Automation Before the 100-Day Limit

Forty percent of respondents chose “very prepared – we already have automated systems in place to manage monthly renewals.” Sectigo asked every respondent what share of their certificates they automate for each task, but it published no cross-tabulation showing how the “very prepared” group answered. Across all respondents, 15% say they automate more than 70% of their certificate renewals, and 4% more than 90%. Sixty-one percent automate half or fewer. I would ask anyone who chose “very prepared” what share of their renewals need no one to intervene.

Under the old 398-day maximum, a certificate outside automation needed about one manual renewal a year. At 100 days it needs about four. At 47 days, the maximum from March 15, 2029, it needs about eight, before any margin for renewing early. Once a CA can reuse a domain validation for only 10 days, renewals spaced more than 10 days apart will each need a new validation.

Let’s Encrypt announced on October 7 that its certificates will be valid for 64 days by default from February 10, 2027, five weeks before the 100-day limit takes effect. It plans to move the default to 45 days in 2028.

Fourteen percent of respondents automate DCV for more than 70% of their certificates. Eight percent automate revocation to that level. Of the averages Sectigo published, revocation’s is the lowest, at 37%.

On October 18, eMudhra, an India-based CA, revoked eight intermediate CA certificates whose private keys anyone could compute. The company said about 30,000 certificates chaining to the affected root must move to its RSA root and that about 97% of them came through ACME, so most can be reissued without anyone touching a server (my analysis).

Sectigo recommends connecting discovery, policy, issuance, validation, deployment, monitoring, revocation and reporting into a governed operating model. I agree, and I would measure progress by the share of certificates that nobody has to touch from request through renewal.

Public and Private PKI Will Change on Different Schedules

In its headline question, Sectigo asked to what extent “today’s public key infrastructure” will need to structurally change to support PQC. It did not separate the publicly trusted web PKI from the private PKIs organizations run themselves, even though different parties are changing the two.

In February, Google’s Chrome team said it had no immediate plan to add X.509 certificates containing post-quantum cryptography to the Chrome Root Store and would develop MTCs instead (my analysis). Google plans to invite established CT log operators to bootstrap public MTCs in the first quarter of 2027. In the third quarter, it plans to finalize the requirements for onboarding more CAs into a separate Chrome Quantum-resistant Root Store. Cloudflare plans post-quantum authentication for visitor connections using MTCs by mid-2027. Let’s Encrypt has committed to MTCs. TrustAsia and Geomys filed as Chrome MTC test operators in July.

The PLANTS working group published version -07 of the MTC draft on October 7. Its authors work at Google, Apple, Cloudflare and Geomys. Among the 18 people they thank for discussions, feedback and contributions is Sectigo’s Rob Stradling. The authors define extensions for requesting MTCs through the Automatic Certificate Management Environment (ACME), the IETF’s standard protocol for automated certificate issuance. They base their size estimates on a seven-day certificate lifetime. Sectigo’s figures are consistent with the draft. The authors give 2,420 bytes for an ML-DSA-44 signature and 736 bytes for their example inclusion proof in a landmark-relative certificate, the optimized form that omits signatures. Servers present standalone MTCs, which include signatures, to clients without the predistributed log data.

For a company’s public websites, browser vendors and CAs are setting most of the architecture. The company still has to automate issuance and deployment, make sure its TLS servers and content delivery networks (CDNs) can serve the new certificate types, and test them with its users’ browsers and other clients. Cloudflare notes that a site with post-quantum certificates is protected from downgrade attacks only once its operator disables the quantum-vulnerable options or, for HTTPS, uses PQ HSTS or Certificate Transparency to prevent their use.

Respondents may have had both kinds of PKI in mind. If they expect CAs and browser vendors to make most of the changes to public web certificates, there is no conflict between the 78% who expect PKI to change to a great or very great extent and the 74% who are extremely or very confident they can integrate PQC without major disruption. The same reading may apply to MTCs. Eighty percent of respondents familiar with MTCs said they were very or fairly clear on what MTCs would require of them, for a specification still under revision. For most organizations, what MTCs require will be whatever their CA, CDN and web server vendors ship, together with automation that works end to end.

No browser vendor makes these decisions for a private PKI. Google added ML-DSA support for private PKI hierarchies in Chrome 150, so organizations can now test conventional, directly signed post-quantum X.509 certificates under their own roots. Organizations use private PKIs to sign code and firmware, authenticate devices and workloads over mutual TLS, issue VPN and Wi-Fi certificates, and back smart cards. Their owners will have to choose for each use among post-quantum-only certificates, parallel classical and post-quantum hierarchies, and composite certificates. They will also have to test relying parties that may reject larger certificates, and upgrade or replace hardware security modules (HSMs) that lack ML-DSA support.

With a cryptographically relevant quantum computer, an attacker could derive a private signing key from its public key and forge signatures. I first described this risk in 2018 as “Sign Today, Forge Tomorrow,” and it is now usually called trust now, forge later. Owners of private PKIs should start with the signing keys that relying parties will trust for the longest. The owner of a firmware root that devices will trust for ten years has to replace it long before anyone can forge signatures with it. The owner also has to get the new trust anchor onto devices already in the field and then retire the old one. For software and firmware signing, NSA specifies the stateful hash-based schemes LMS and XMSS in CNSA 2.0, so ML-DSA is not the only option for those roots.

In Quantum Ready I recommend that owners of private PKIs proceed now with conventional X.509 certificates and post-quantum algorithms, without waiting for MTCs, which Google is building for the public web. For agencies’ high value assets and high-impact systems, the EO 14412 deadline for post-quantum digital signatures is December 31, 2031.

NIST Published Its Final Transition Schedule the Day Before the Report

Sectigo writes that under NIST’s transition plan, legacy public-key algorithms will be deprecated by 2030 and disallowed by 2035. NIST published the final version of that plan, NIST IR 8547, on October 27. In the final, NIST deprecates quantum-vulnerable signature and key-establishment algorithms, including RSA, ECDSA, EdDSA and elliptic-curve Diffie-Hellman, after 2030 and disallows them after 2035. In the November 2024 draft (my analysis), NIST had proposed moving 128-bit-strength algorithms such as ECDSA on P-256 straight to disallowance after 2035, with no deprecation period. In the final, NIST deprecates them after 2030 as well.

Sectigo’s summary matches the final, with two qualifications. NIST writes “after” 2030 and 2035, where Sectigo writes “by.” NIST also applies the dates to what its own standards and guidelines allow, which federal agencies must follow. For agencies’ high value assets and high-impact systems, NIST notes that the earlier deadlines in OMB’s Memorandum M-26-15 apply.

Where the 47-Day Work Overlaps With PQC Migration, and Where It Does Not

Ninety-six percent of respondents saw at least some overlap between preparing for 47-day certificates and preparing for PQC. An organization that can find, renew and revoke every public TLS certificate quickly has removed one barrier to changing the algorithms in those certificates. It still has to confirm that its endpoints, HSMs, cryptographic libraries and relying parties support the new ones. Sectigo has made the overlap argument since its 2025 report. I make a related one: crypto-agility should be the goal of a PQC program, with the migration as its first test.

The 18% who said the two are exactly the same are describing a smaller program than PQC migration. SC-081v3 applies only to publicly trusted TLS certificates. It does not apply to SSH keys, IPsec and VPN key exchange, storage encryption that wraps keys with RSA, CA root keys held in HSMs, code- and firmware-signing roots, payment systems, operational technology (OT) devices or the cryptography inside vendor products. An organization that answered “exactly the same” may scope its PQC migration to the certificates its CLM program manages and leave those systems out.

Even on public websites, an organization can’t address HNDL by shortening certificate lifetimes. In an HNDL attack, which 63% of respondents were extremely or very concerned about, the attacker records the key exchange and the data encrypted with the session keys derived from it. With shorter certificate lifetimes, operators replace certificates more often but keep the same key exchange algorithm. Against HNDL, Google and Mozilla enable hybrid ML-KEM (formerly CRYSTALS-Kyber) key exchange by default in Chrome and Firefox. Cloudflare reported in April that more than 65% of human traffic to its network was post-quantum encrypted.

What I Would Do With This Report

1. Measure certificate automation end to end before March 15, 2027. Track, by owner, the share of public TLS certificates that nobody has to touch from request and DCV through deployment and renewal. Use ACME. Ask CAs and ACME client vendors for ACME Renewal Information (RFC 9773). With it, a CA can tell clients to renew early, for example ahead of a mass revocation.
2. Investigate every certificate incident as a lifecycle failure. Find out which control failed: inventory, validation, issuance, deployment, application reloads, key handling, monitoring or recovery. Then fix that failure for every other certificate exposed to it.
3. Split the PKI plan in two. For public certificates, ask the CA for its MTC and Chrome Quantum-resistant Root Store plans, and confirm that issuance and deployment automation work end to end. For private PKI, start testing post-quantum hierarchies with Chrome 150 and your other relying parties. First test the code- and firmware-signing roots that relying parties will trust for the longest. Plan how you will distribute new trust anchors to deployed devices.
4. Report public certificate coverage separately. Include the public TLS certificates in the cryptographic inventory, and report their coverage separately from the rest of the estate. For everything other than public TLS, start with the infrastructure and platform layers, as I do in the minimum viable inventory of my PQC Migration Framework, and state the coverage behind every figure.

Chrome’s MTC bootstrapping and the 100-day limit are both scheduled for the first quarter of 2027. If Sectigo fields its next survey in July 2027, as it did this year, respondents will report incidents from a 12-month window, most of which precedes the 100-day limit. On automation, respondents will describe where they stand at the time of the survey. If Sectigo keeps a comparable panel and publishes the renewal average alongside the other tasks, its 2027 report will be the first like-for-like measure of how much certificate work organizations automated as the CA/Browser Forum tightened the limits.

From the author