What MPIC is

MPIC requires a certificate authority to perform domain control validation (DCV) and CAA record checks from multiple geographically- and network-topologically distinct vantage points before issuing a certificate. If the validation succeeds from the CA's primary perspective but fails from secondary perspectives, the issuance is rejected.

The requirement was formalised in CA/Browser Forum Ballot SC-067 (effective March 2025, phased through 2026). The current baseline is 3 corroborating network perspectives in addition to the primary, with the number increasing on a scheduled cadence.

The attack MPIC defends against

An on-path attacker with the ability to announce arbitrary BGP routes can briefly hijack traffic for a specific prefix. If the attacker hijacks a prefix during a certificate authority's domain-control validation, they can serve a forged /.well-known/acme-challenge/ response and receive a certificate for a domain they don't own.

This was not theoretical. In 2022, researchers demonstrated the attack live against several major CAs. BGP hijacks of specific /24s are routine on the public internet — accidental in most cases, deliberate in some. A CA that validates only from its own datacenter sees whatever the hijacker shows it.

MPIC makes the attack much harder: the attacker would need to simultaneously hijack the prefix from the perspective of all 3+ CA validation vantages, which requires compromising multiple upstream networks at once. Possible but considerably more expensive.

How it works

CA receives an order. The requester provides identifiers (domain names) to validate.
CA issues validation challenges. Standard ACME-style HTTP-01, DNS-01, or tls-alpn-01.
CA fetches the validation response from the primary perspective. This is the CA's own primary network location.
CA fetches the same validation response from N secondary perspectives. Secondaries are typically operated by the CA in different network regions, or outsourced to independent vantage providers.
CA compares results. All perspectives must agree (same token, same DNS record, same TLS response). If any one perspective disagrees, issuance is rejected.
CA proceeds with issuance. If all perspectives agree, DCV is considered complete.

The same applies to CAA record lookups — the CAA policy must resolve consistently from multiple vantages.

Who operates perspectives

Public CAs typically operate multiple perspectives directly (multiple DC regions, multiple cloud providers) and may contract with independent vantage providers to add diversity. Let's Encrypt, Sectigo, and DigiCert all run MPIC with fully-disclosed perspective lists; the CA/B Forum tracks which CAs are MPIC-compliant.

Operational implications for domain owners

MPIC is mostly transparent to end users and domain owners, but has specific operational gotchas:

Firewall rules

A firewall or WAF that whitelists specific CA source IPs breaks under MPIC. The CA now reaches your /.well-known/acme-challenge/ endpoint from multiple distinct source networks. Allowlists that were sufficient at single-perspective validation fail at multi-perspective.

Fix: remove the IP allowlist for the challenge path, or switch to DNS-01 which validates via your DNS provider's public API (no inbound traffic required).

Geo-blocked endpoints

A TLS endpoint that is only served from certain geographies (because of GDPR data residency, regulatory restrictions, or CDN configuration) will fail MPIC if perspectives in blocked geographies see different responses than the primary.

Fix: use DNS-01 instead of HTTP-01, or ensure the challenge path is globally reachable.

DNS-01 and MPIC

DNS-01 is typically more MPIC-friendly than HTTP-01, because DNS resolution converges globally within a few minutes of a TXT record publish. Perspectives with DNS caches may briefly disagree, but the time window is small.

Validation timing

MPIC adds latency to the validation step — the CA has to fetch from multiple perspectives sequentially or in parallel. Overall issuance time may be slightly longer; renewal pipelines should tolerate the extra seconds.

MPIC and the broader WebPKI improvement arc

MPIC pairs with:

Certificate Transparency — detection of misissuance after the fact.
CAA records — policy enforcement before issuance.
Short-lived certificates — limiting blast radius of any misissuance.
DNSSEC — authenticating DNS responses (reduces the DNS-level hijack surface).

Each of these addresses a different failure mode. MPIC specifically addresses the BGP-hijack-during-validation attack. The combination is the modern WebPKI's defence in depth.

MPIC