When multiple organizations share a single TLS private key.

A single quantum decryption then unlocks all of them. The blast radius compounds across organizational boundaries — usually invisibly to either side.

What is cross-organizational key sharing?

In TLS, every certificate is bound to a public key, and the matching private key is the secret that decrypts the session. Most operators assume their key is theirs alone. In practice, several common configurations cause keys to be shared across organizations that don't realize they share them:

• CDN multi-tenancy. Some CDN tiers issue one wildcard cert backed by one private key, then serve dozens-to-hundreds of customer origins via SNI under that single key. Each customer believes they have their own crypto boundary; in reality, one key compromise affects every customer on that shared CDN tier.
• Hosting platform shared certs. Squarespace, Wix, Webflow, and other website builders historically issued one cert per platform region rather than per customer site. Same key, many customer brands.
• SaaS-issuer crypto pools. Some legacy SaaS providers reused a small pool of private keys across customer subdomains for operational simplicity. A compromise of one key touches every tenant on that pool.
• White-label resellers. Some resellers ship the same cert (and key) across every customer instance under their brand. The blast radius is the entire reseller's customer base.
• Misconfigured load balancers. Some configurations distribute one key across an unintended set of subdomains owned by acquisitions or subsidiary brands.

Why it matters for HNDL

The Decryption Blast Radius score (see methodology) factors in subdomain scale — how many subdomains are covered by a wildcard SAN under one key. Cross-organizational key sharing extends that multiplier to crossing organizational boundaries — a fact most procurement teams aren't aware of when they review their vendors' security postures individually.

"If a compromised CDN private key serves 200 customer brands, the blast radius is 200× that of a single first-party domain. None of those 200 customers can fix it themselves — only the CDN can rotate the key. Until they do, every customer's traffic remains harvested-decryptable in lockstep."

Detection methodology

For each cert in our scan corpus, we extract the public key and compute its SHA-256 fingerprint. We then group certificates by fingerprint and identify cases where:

• The same key fingerprint appears across different registered domains (different eTLD+1).
• The cert subjects (Common Name, Organization Name) belong to different organizations.
• The cert lifetimes overlap (the keys were live simultaneously, not chronologically reused).

We then publish the findings — but only after manual review confirms the cross-org assignment is genuine (not a false positive from bare CDN front-end / customer back-end relationship that the customer is aware of).

What we already detect (per-domain key reuse)

While the cross-corpus analysis matures, our existing per-domain key-reuse detection IS live. For any single domain, we extract every certificate ever issued for it from Certificate Transparency logs, group them by public-key fingerprint, and surface the longest key-reuse window. This is documented at DBR methodology, Probe 2.

Empirically: 4-6 year key-reuse windows are common at large banks and healthcare systems. We've seen up to 8 years on a single domain. Cross-corporate key sharing extends those windows by an order of magnitude.

Press / research inquiries

For early access to specific findings (e.g., journalists writing about CDN security, vendor-risk teams evaluating SaaS providers, academic researchers): press@cipherwake.io or /feedback.

For methodology questions or to challenge our detection logic publicly, see /methodology. We revise rather than defend.