> PKI for senior management: what certificates are, why they cause outages, what 47-day lifetimes cost, post-quantum planning and ten questions to ask. Source: https://pkizerotohero.com/leaders/ · Last reviewed: 2026-10-19 # PKI for leaders in 10 minutes Last reviewed 19 October 2026 PKI is the system your organisation uses to prove who it is online and to check who it is talking to; when it fails, services stop and trust breaks, so it needs an owner, automation and a plan. **Who this page is for:** senior managers, risk and compliance officers, auditors and anyone who has to decide about certificates without configuring them. It takes about ten minutes. Engineers will find the details in the [handbook](https://pkizerotohero.com/handbook/) and the dates on [What’s changing in PKI](https://pkizerotohero.com/changes/). ## What is PKI, in business terms? PKI stands for public key infrastructure. Think of it as the system of **digital ID cards** for your organisation: - A **certificate** is a digital ID card for a website, a service, a device or a piece of software. It says “this public key belongs to this name”. - A **certificate authority (CA)** issues certificates after checking the request. Browsers and operating systems trust only a limited list of CAs. - Each certificate is paired with a **private key**, a secret that stays with the owner. Whoever holds the private key can act as you, so it must be protected. - Every certificate has an **expiry date**. That is deliberate: it limits the damage if something goes wrong. Your organisation depends on PKI whether or not anyone manages it: every website and API, many VPNs and Wi-Fi networks, email security, signed software, and devices that talk to each other. Why it matters to the business Three things to manage **Certificates** expire, so someone must renew them on time. **Private keys** must stay secret, so someone must know where they are and who can reach them. **Trust** depends on CAs and vendors that browsers can stop trusting, so someone must be able to switch quickly. If nobody owns these three, you have a risk, not a system. ## Why do certificates cause outages? An expired certificate does not slow a service down; it stops it. Browsers show a full-page warning, and apps, APIs and devices simply refuse to connect. The expiry date is known from the day the certificate is issued, yet expiry remains a common cause of outages, because: - nobody knows the certificate exists, or who owns it; - renewal is a manual task, done once a year by someone who has since left; - the warning emails go to a mailbox nobody reads; - the new certificate was installed, but the service was never restarted to use it. Trust can also break from outside: browsers can stop trusting a CA, and old root certificates expire. Then certificates must be replaced or devices updated, whoever bought them. Public examples: - 2011: DigiNotar was breached, issued fraudulent certificates and was removed from browser trust stores. - 2018: Chrome and Firefox stopped trusting TLS certificates from Symantec's old CA infrastructure. - 30 September 2021: DST Root CA X3, the older root that had cross-signed Let's Encrypt, expired, so devices that did not trust ISRG Root X1 began rejecting Let's Encrypt certificates. - 12 November 2024: Chrome stopped trusting new Entrust TLS certificates (those first logged in Certificate Transparency after 11 November 2024). The handbook’s [Famous failures and what changed](https://pkizerotohero.com/handbook/famous-failures/) tells these stories, with sources, and what each one taught the industry. ## What does the 47-day shift mean for budgets? Browsers and CAs have agreed to shorten the life of public TLS certificates, the ones that secure websites and APIs: | From | Maximum lifetime | | --- | --- | | 15 March 2026 | 200 days | | 15 March 2027 | 100 days | | 15 March 2029 | 47 days | By then, every public certificate must be replaced at least eight times a year. The reason is good security: a stolen key or a wrong certificate stays useful to an attacker for weeks, not a year. The consequence is that renewal by hand stops being affordable or safe. What it means for your budget and plans: - **Automation is no longer optional.** The standard protocol, ACME, is free and widely supported. The cost is the engineering time to connect it to every server, load balancer and appliance, and to test it. - **Some equipment cannot automate.** Older appliances that need a person to upload a certificate will need replacing, or a proxy in front of them. - **Procurement should ask.** Make “supports automated certificate renewal (ACME)” a requirement for hosting, appliances and services that use your domain names. - **Check your CA contract.** With many renewals a year, per-certificate pricing and manual approval steps add up. - **Plan in stages.** The step to 100 days on 15 March 2027 is the real test. Automate before it, not after the first outage. Why it matters to the business A decision to make this quarter Set a date by which every public certificate renews automatically and is monitored, and name an owner for it. A date well before 15 March 2027 gives your teams room to find the systems that cannot automate. ## How should we plan for post-quantum cryptography? A large enough quantum computer could break the public-key cryptography in use today. No such machine exists today, and nobody can promise when one will. Treat it like any long, uncertain risk: plan calmly, start early, avoid panic purchases. What is already settled: - **Standards exist.** NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) on 13 August 2024. - **Browsers have started.** X25519MLKEM768 hybrid post-quantum key exchange is on by default in Chrome, Firefox and Apple's operating systems (late 2024 in Chrome 131 and Firefox 132). - **Governments have set a direction.** NIST proposes deprecating quantum-vulnerable public-key algorithms at the 112-bit security level after 2030 and disallowing all of them after 2035. The EU’s roadmap says EU member states should start the transition by the end of 2026, finish it for high-risk use cases by the end of 2030 and complete as much as feasible by 2035. Why start now: data recorded today could be decrypted later (“harvest now, decrypt later”), and replacing cryptography across products, devices and partners takes years. A sensible plan: 1. **Inventory** where you use cryptography, and which data must stay confidential for many years. 2. **Ask vendors** for their post-quantum roadmap and dates, and put it in contracts. 3. **Build in agility:** systems that can change algorithms through configuration, not a rewrite. 4. **Budget across years,** starting with long-lived secrets and devices that stay in the field for a decade. Be careful with products sold as “quantum-proof” today. Follow the published standards and your main vendors. ## Why do NIS2 and DORA make PKI relevant? Two EU laws name the topics PKI belongs to: - **NIS2** lists, among its cybersecurity risk-management measures, basic cyber hygiene practices and cybersecurity training (NIS2 Directive (EU) 2022/2555, Article 21(2)(g)) and policies and procedures regarding the use of cryptography and, where appropriate, encryption (NIS2 Directive (EU) 2022/2555, Article 21(2)(h)). - **DORA** requires financial entities to have ICT security awareness programmes and digital operational resilience training (DORA Regulation (EU) 2022/2554, Article 13(6)). A written cryptography policy, a certificate inventory and staff who understand certificates are natural parts of that work. Whether these laws apply to your organisation, and what they require of you, depends on your sector, size and country. Note Relevance, not compliance This page explains why PKI knowledge is relevant to these laws. It is not legal advice. Using this site, or any training, does not by itself meet a legal obligation. Ask your legal and compliance advisers what applies to you. ## Ten questions to ask your team 1. **How many certificates do we have, where are they, and who owns each one?** A good answer is a list, not a guess. It includes internal CAs, devices and cloud services. 2. **Which certificates renew automatically today, from request to install and reload?** Ask for the share that is fully automatic, and the list of the rest. 3. **When did a certificate last expire on us, or nearly expire, and what did we change afterwards?** A near miss is only useful if it led to a fix. 4. **Are we ready for 100 days certificates on 15 March 2027?** Ask which systems will break first, and what it costs to fix them. 5. **Who is warned before a certificate expires, and does that warning reach someone who can act?** Monitoring should be separate from the renewal tool, so a failed renewal still raises an alarm. 6. **Where are our private keys, who can reach them, and how fast could we replace one that leaked?** A good answer names a process and a time, for example “within a day”. 7. **If browsers stopped trusting our certificate authority tomorrow, how long would it take to switch?** It has happened to large CAs. Days is good; months is a risk. 8. **Do we use public certificates for anything other than websites, such as partner connections with mutual TLS?** Public certificates are being limited to websites. Those other uses will need a private CA or certificates made for that purpose. 9. **Do we have a written cryptography policy, and does it say how we will move to post-quantum algorithms?** It does not need to be long. It needs an owner and a review date. 10. **Who could fix a certificate outage at 2 a.m., and how do we make sure it is more than one person?** Knowledge in one head is a single point of failure. ## What should I do next? - **Get the dates:** [What’s changing in PKI](https://pkizerotohero.com/changes/), updated every quarter. - **Get the big picture in about 90 minutes:** the [crash course](https://pkizerotohero.com/course/) has ten short lessons for busy people, with no account needed. - **Give your engineers the detail:** [Inventory, expiry and renewal](https://pkizerotohero.com/handbook/certificate-lifecycle/), [ACME and the 47-day schedule](https://pkizerotohero.com/handbook/acme/), [A CA of your own](https://pkizerotohero.com/handbook/private-ca/) and [Post-quantum cryptography](https://pkizerotohero.com/handbook/post-quantum/). - **Train a team:** [teams](https://pkizerotohero.com/teams/) with yearly seats, verified credentials and a completion report are planned. [Notify me when it opens](mailto:info@pkizerotohero.com?subject=Notify%20me%20when%20PKI%20Zero%20to%20Hero%20opens).