Every publicly trusted TLS certificate starts with domain control validation. The methods are listed in the CA/Browser Forum Baseline Requirements and you have almost certainly used one of them without reading its name. If you have run an ACME client, you have answered an http-01 challenge by placing a file under /.well-known/acme-challenge/, or a dns-01 challenge by publishing a TXT record at _acme-challenge, or a tls-alpn-01 challenge in the TLS handshake itself.
All three share a structure. The CA generates a random token, tells you where to put it, then goes and looks. If the token is there, the CA concludes you control the domain and signs a certificate for it.
The part that took the industry a long time to treat as a real problem is the word looks. Looking means resolving a name and connecting to an address, and both of those steps hand the outcome to whichever network the packets actually traverse.
Routing decides who gets asked
The internet moves traffic between networks using BGP, which is a system of assertions. A network operator announces "traffic for this range of addresses should come to me," neighbours accept the announcement, and it propagates. There is no built-in proof that the operator is entitled to the range. We covered how that goes wrong in its own right.
Now put the two together. If an attacker can get part of the internet to send traffic for example.com's IP range to their own network, they do not need to break any cryptography to get a certificate for example.com. They just need the certificate authority's validation query to arrive at their machine instead of the real one. They answer the challenge, the CA sees a correct token, and a genuine, publicly trusted certificate is issued to the wrong party.
This is not theoretical. Researchers at Princeton demonstrated it against real certificate authorities and published the results at USENIX Security in 2018, in a paper titled Bamboozling Certificate Authorities with BGP. They showed that an attacker does not even need a global hijack. A more specific prefix announcement, or an equally specific one that only needs to win the route selection at the CA's own network, is enough to capture the validation traffic while the rest of the world continues to reach the real site undisturbed.
A short, narrowly targeted hijack only has to divert the CA's validation query for the seconds it takes to answer a challenge. The victim's users are not affected, the victim's monitoring sees normal traffic, and the resulting certificate is cryptographically indistinguishable from a legitimate one.
The fix is a quorum, not stronger cryptography
Nothing about the challenge itself is weak. The token is random, the transport can be authenticated, the signature on the resulting certificate is sound. The failure is that a single observation was treated as ground truth about a network whose routing is negotiated rather than authoritative.
Multi-Perspective Issuance Corroboration, usually shortened to MPIC, changes the observation. Instead of validating once from the CA's primary network location, the CA repeats the validation from several additional network perspectives in different parts of the internet, then requires the answers to agree before issuing.
A narrowly scoped hijack now has to be wide enough to capture every perspective at once. Announcing a prefix that beats the real one at four or five distinct networks scattered across regions is a much larger, much louder operation than beating it at one. It is more likely to be seen by BGP monitoring, more likely to disrupt real users, and more likely to leave evidence.
Let's Encrypt shipped multi-perspective validation in production in February 2020 and has run it since. The larger change is that this stopped being one CA's engineering decision. Ballot SC-067 added MPIC to the Baseline Requirements, with enforcement beginning on 15 March 2025 and the number of corroborating perspectives increasing over a published schedule after that. The requirements also constrain where the perspectives may sit, using geographic and network-topology separation so that the set does not quietly collapse into several machines behind one upstream provider.
| Property | Single-perspective validation | MPIC |
|---|---|---|
| Attacker must divert | One network path | A quorum of separated paths, simultaneously |
| Visible to BGP monitoring | Often not, if narrowly scoped | Much harder to keep narrow |
| Impact on the real site | Usually none | Broad hijack tends to disrupt real users |
| Detects a compromised registrar | No | No |
| Detects mis-issuance after the fact | No | No, that is CT's job |
What MPIC does not cover
The last two rows of that table are the interesting ones, because MPIC addresses exactly one class of attack and it is worth being precise about the boundary.
If an attacker controls your DNS at the source rather than in transit, every perspective sees the same forged answer and agrees perfectly. That covers a compromised registrar account, a compromised authoritative DNS provider, and a dangling record pointing at infrastructure someone else can claim. Corroboration only detects disagreement, and there is no disagreement when the lie is told at the origin. Registrar hardening is a separate control and remains the one that matters most for that path.
MPIC also does nothing about a CA that misbehaves or is compromised internally, and nothing about a certificate that has already been issued. Those are covered by other layers: CAA records let you state which CAs are allowed to issue for your domain at all, and Certificate Transparency gives you a public log to watch so that mis-issuance is discoverable after the fact rather than never.
The complementary control on the routing side is RPKI with route origin validation, which lets you publish a signed statement about which network is entitled to originate your prefixes. MPIC makes the hijack harder to keep small; RPKI makes the hijack harder to launch at all. Neither replaces the other.
What to do with this if you operate a domain
MPIC is a CA-side requirement, so the good news is that you get it without doing anything. The parts still on your side are the ones it deliberately does not touch:
- Publish CAA records. They cost one DNS entry and they narrow the set of CAs that will issue for you at all, which shrinks the surface MPIC is defending in the first place.
- Lock the registrar account. Registry lock, hardware-backed multi-factor, and a small set of named humans. A registrar compromise defeats every validation method in the Baseline Requirements.
- Publish RPKI ROAs for your prefixes if you run your own network, and ask your provider whether they do if you do not.
- Watch Certificate Transparency for your names. Free monitors exist. This is the control that tells you a certificate was issued that you did not request.
There is a broader pattern here that shows up whenever a security decision rests on a network measurement. The cryptography around the measurement can be flawless while the measurement itself is being fed by an adversary, and the countermeasure is rarely a better algorithm. It is usually more observers, placed far enough apart that lying to all of them at once is expensive. Certificate Transparency does the same thing with logs, and trust-on-first-use key verification struggles for the mirror-image reason, because it has exactly one observer and no way to compare.