With encryption nearly everywhere, attackers have adjusted their playbook. Below are the threat trends that show up most often around TLS − and what they mean for people running TLS at scale.
1) Phishing with HTTPS is now the default
Phishers figured out years ago that they can get valid TLS certificates cheaply (or free) for look-alike domains. So the padlock tells you “this connection is encrypted”, not “this site is trustworthy”. Recent reporting puts HTTPS usage on phishing sites at roughly three-quarters or more.
This means user education has to evolve from “look for the padlock” to “verify the domain (and context)”. For administrators, it also strengthens the case for Certificate Transparency monitoring to spot look-alike domains and unexpected certificates for your brand before they become a support or incident-response problem. Treat “TLS present” as table stakes; focus detection on identity (domain, sender, brand signals) and exposure (new cert issuance, typosquats).
2) MitM is harder − but certificate and key abuse still matters
Classic on-path attacks are less convenient than they used to be: browsers warn loudly on non-HTTPS traffic, and legacy crypto is largely pushed out. That said, high-end attackers can still aim for “trust subversion” − for example, by abusing certificate issuance processes, compromising validation paths, or stealing secrets.
We’ve seen how catastrophic CA failures can be (e.g., DigiNotar), and we still see modern reminders that digital certificates and keys are valuable loot. In Cisco’s 2024 DevHub incident, leaked data was reported to include digital certificates among other artifacts. [1] More recently, unauthorized certificate issuance incidents − such as the 2024-2025 Cloudflare 1.1.1.1 misissuance case where 12 TLS certificates were issued without authorization − highlight ongoing risks in certificate validation processes. [2] And attackers continue to abuse code-signing certificates, with 2025 campaigns abusing Microsoft’s Trusted Signing service to sign malware with short-lived certificates. [3]
So “Protect private keys” isn’t a platitude − it’s a control objective. Short-lived certificates, automated rotation, and tight key handling reduce the blast radius when something leaks. Assume secrets will leak eventually; optimize for fast detection (CT + inventory) and fast recovery (rotation + revocation workflows).
3) TLS in the enterprise: inspection vs. privacy keeps getting messier
A lot of enterprises still perform TLS interception (via a private root CA) to inspect traffic for security monitoring. That can work − but it creates a concentrated risk: if that private root or inspection stack is compromised, you’ve effectively built your own on-path attacker.
Meanwhile, encryption is getting “more opaque by design” (think ECH and the move to QUIC), which makes passive inspection less reliable and pushes security controls closer to endpoints. The trend is toward endpoint enforcement (identity, device posture, authorization) rather than “decrypt everything at the perimeter”.
If you’re in microservices land, mTLS inside the mesh becomes a common pattern − and that dramatically increases the number of certificates you issue and rotate. The security story improves, but only if certificate lifecycle management is automated and your internal PKI is operated like a real production system. If you rely on interception, treat it as a high-risk tier-0 component; if you move to mTLS, budget for automation and inventory from day one.
4) The protocol is solid; implementation and configuration keep biting
We still see flaws in TLS implementations and integrations − especially around certificate validation, hostname verification, and chain handling (common in embedded/IoT stacks and “rolled-your-own TLS” situations). And some issues aren’t a “TLS is broken” story so much as “TLS was used in a risky pattern”, like the cross-protocol confusion class described by ALPACA. [4]
Modern incidents skew toward bugs, outdated dependencies, and misconfigurations, not a dramatic new break of TLS 1.3 itself. So the unglamorous work matters most: patching, sane defaults, and keeping crypto libraries current (OpenSSL, NSS, etc.). Your TLS posture is often determined by dependency hygiene and configuration governance, not by which version number you put in a slide deck.
5) The quantum threat is not “today”, but planning is
This remains a “harvest now, decrypt later” concern: attackers can record encrypted traffic now and try to decrypt it later if cryptographically relevant quantum computing becomes practical.
Regulators and standards bodies are already pushing timelines. NIST’s draft transition guidance references a 2035 target for completing migration across U.S. federal systems. [5] And NIST has been finalizing post-quantum standards as part of that transition. [6]
The useful action now isn’t “rip and replace everything”, it’s preparing your TLS stack to adopt PQC safely − often via hybrid key exchange approaches during the transition period. The IETF has active work on hybrid key exchange in TLS 1.3. [7] Start with discovery (where is public-key crypto used?), then make TLS endpoints “upgrade-ready” (modern versions, flexible cipher/KEM configuration, automation).
Sources
- Cisco Confirms Authenticity of Data After Second Leak - SecurityWeek
- Addressing the unauthorized issuance of multiple TLS certificates for 1.1.1.1 - Cloudflare
- Microsoft Trusted Signing service abused to code-sign malware - BleepingComputer
- CVE-2021-3618 Detail - NVD
- NIST IR 8547 initial public draft, Transition to Post-Quantum Cryptography - NIST Publications
- NIST Releases First 3 Finalized Post-Quantum Encryption Standards - NIST
- Hybrid key exchange in TLS 1.3 - IETF Datatracker