> Lesson 10 of PKI in 90 minutes: mutual TLS, code signing with timestamps, device identity, and what post-quantum cryptography changes and when. Source: https://pkizerotohero.com/course/beyond-the-browser/ · Last reviewed: 2026-10-20 # Beyond the browser, and what comes next About 8 minutesCrash course **In one sentence:** The same building blocks secure APIs with mutual TLS, software with code signing and devices from the factory, and post-quantum cryptography is the next change to plan for. ## The situation A partner bank emails: “From next quarter, calls to our payment API require mutual TLS. Please send us your client certificate.” The same week, your usual public CA announces that its certificates will no longer support client authentication. Where will that certificate come from? And what else in your company quietly depends on certificates outside the browser? ## What is going on Everything in this course so far (key pairs, signatures, certificates, chains and trust stores) works the same way far beyond websites. *Diagram: In the centre, the same building blocks: key pairs, certificates, chains and trust stores. Around them, four uses: mutual TLS, where both sides show a certificate; code signing, which shows the publisher and adds a timestamp; device identity, a certificate from the factory with the key in secure hardware; and post-quantum cryptography, with hybrid key exchange now and new signatures next.* Four places PKI works outside the browser, all built from the same parts. ### Both sides show ID: mutual TLS In [mutual TLS](https://pkizerotohero.com/handbook/glossary/#mutual-tls) (mTLS), the server asks the client for a certificate during the handshake. The client sends its certificate and the same kind of CertificateVerify signature the server gives (lesson 7). Both sides are now authenticated. It is common for APIs, for traffic between services, and for devices. Public CAs are leaving this job. Chrome's root program starts phasing out root hierarchies that are not dedicated to TLS server authentication (from 15 June 2026), and Let's Encrypt certificates no longer include the TLS client authentication purpose (from 11 February 2026 for the default profile, and 8 July 2026 for the last opt-in profile). Client certificates therefore come from a private CA (lesson 9) or a provider dedicated to them. Agree with the partner which CA they will trust for your clients. ### Signed and sealed: code signing Publishers sign software with a [code-signing](https://pkizerotohero.com/handbook/glossary/#code-signing) certificate, and operating systems can check the signature before installing or running it. A valid signature says who published the code and that nobody changed it. It does **not** say the code is safe. Malware signed with stolen keys is a known problem, which is one reason code-signing keys belong in hardware. A trusted [timestamp](https://pkizerotohero.com/handbook/glossary/#timestamp), added while the certificate is still valid, proves when the signature was made. Checkers can then still verify the signature after the certificate expires. The same idea signs PDFs and contracts. In the EU, the [eIDAS Regulation](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02014R0910-20240520) says that a qualified electronic signature shall have the equivalent legal effect of a handwritten signature (Regulation (EU) No 910/2014, Article 25(2)). ### Machines with passports: device identity Routers, smart-home devices, smart meters and industrial sensors increasingly get a certificate at the factory. The private key is generated inside secure hardware on the device and never leaves it, so the device can prove what it is without a shared password. ### The quantum storm A large enough quantum computer would break today’s public-key algorithms, RSA and elliptic curves, in both key exchange and signatures. Symmetric ciphers and hashes are only weakened; 256-bit keys such as AES-256 keep a comfortable margin. The urgent risk is “harvest now, decrypt later”: traffic recorded today could be decrypted in the future. So key exchange moves first. NIST published the first [post-quantum](https://pkizerotohero.com/handbook/glossary/#post-quantum-cryptography) standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), on 13 August 2024. X25519MLKEM768 hybrid post-quantum key exchange is on by default in Chrome, Firefox and Apple's operating systems. Post-quantum signatures and certificates come later; they are much larger, which affects every handshake. Timelines are taking shape: NIST proposes deprecating quantum-vulnerable public-key algorithms at the 112-bit security level after 2030 and disallowing all of them after 2035, according to NIST IR 8547 (initial public draft, November 2024). The EU’s coordinated 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. Being ready to swap algorithms, called [crypto-agility](https://pkizerotohero.com/handbook/glossary/#crypto-agility), starts with the inventory and automation from lesson 9. Why it matters to the business Ask your team Where do we use client certificates, code signing or device certificates, and which CA issues them? Do we know which of our systems use RSA or elliptic-curve keys, and who owns our post-quantum plan? ## Try it *Interactive tool: Certificate decoder (runs in the browser at [/tools/decoder/](https://pkizerotohero.com/tools/decoder/))* Find the Extended Key Usage field. A website certificate lists TLS server authentication (`serverAuth`); a client certificate for mutual TLS needs client authentication (`clientAuth`). Which does this one allow? ## Check Check yourself In mutual TLS, what does each side prove? 1. Both the server and the client present a certificate and prove they hold its private key 2. Only the server proves its identity; the traffic is then encrypted twice 3. The client sends a password inside its certificate Show answer Answer A Both the server and the client present a certificate and prove they hold its private key What happened Both sides send a certificate and sign the handshake with the matching private key, so each authenticates the other. Why mTLS is not 'HTTPS twice'. The encryption is the same; what changes is that the client is authenticated with a certificate instead of a password or API key. The rule In mTLS, both sides prove possession of a private key whose certificate the other side trusts. Check yourself A code-signing certificate expired last month. An installer signed with it two years ago carries a trusted timestamp. What happens when someone checks the installer today? 1. The signature can no longer be verified 2. The installer must be signed again by its users 3. The signature still verifies, because the timestamp proves it was made while the certificate was valid Show answer Answer C The signature still verifies, because the timestamp proves it was made while the certificate was valid What happened The signature still verifies. Why The timestamp authority's own signature shows when the code was signed. The checker confirms the certificate was valid at that moment, not today. The rule Timestamp every code signature while the certificate is valid; it keeps signed software verifiable after the certificate expires. Check yourself Why are browsers already switching key exchange to post-quantum hybrids, while certificates still use classic signatures? 1. Recorded traffic could be decrypted later by a future quantum computer, but a signature only has to resist forgery at the moment of the handshake 2. Quantum computers can already forge today's certificates 3. Post-quantum signatures are not allowed in the EU Show answer Answer A Recorded traffic could be decrypted later by a future quantum computer, but a signature only has to resist forgery at the moment of the handshake What happened Key exchange protects secrets that must stay secret for years, so it is upgraded first. Why An attacker can record traffic now and decrypt it once a quantum computer exists: harvest now, decrypt later. A forged signature, by contrast, is only useful while the handshake is happening. The rule Move key exchange to post-quantum first; plan signatures and certificates next, with crypto-agility. ## Takeaways - Mutual TLS, code signing and device identity use the same parts as HTTPS. Client certificates are moving to private or dedicated CAs. - A signature says who published code and that it is unchanged, not that it is safe; a timestamp added while the certificate is valid keeps it verifiable after expiry. - Quantum computers threaten public-key algorithms: move key exchange first, then signatures, and use your inventory and automation to make the switch. ## Go further - Handbook: [Both sides show ID: mutual TLS](https://pkizerotohero.com/handbook/mutual-tls/) - Handbook: [Signed and sealed: code and document signing](https://pkizerotohero.com/handbook/code-signing/) - Handbook: [Machines with passports: device identity](https://pkizerotohero.com/handbook/device-identity/) - Handbook: [Post-quantum cryptography](https://pkizerotohero.com/handbook/post-quantum/) - Where next: the [handbook](https://pkizerotohero.com/handbook/) for depth, the [browser tools](https://pkizerotohero.com/tools/), and the [game](https://pkizerotohero.com/play/), whose first levels are playable now. **Early edition.** Checked against the standards; an independent expert review is in progress. Found a mistake? [Tell us](https://pkizerotohero.com/contact/?topic=content-error&page=/course/beyond-the-browser/). Last reviewed 20 October 2026Edition 0.9 ## Go deeper in the handbook - [Chapter 23: Both sides show ID: mutual TLS](https://pkizerotohero.com/handbook/mutual-tls/) - [Chapter 24: Signed and sealed: code and document signing](https://pkizerotohero.com/handbook/code-signing/) - [Chapter 25: Machines with passports: device identity](https://pkizerotohero.com/handbook/device-identity/) - [Chapter 26: Post-quantum cryptography](https://pkizerotohero.com/handbook/post-quantum/)