¶ºÒõ¹Ý

When attackers manipulate internet routing, they sometimes trick certificate authorities (CAs) into issuing certificates for domains they don’t actually control. That's the problem Multi-Perspective Issuance Corroboration (MPIC) was designed to prevent: By verifying domain control from multiple points on the internet, MPIC adds a crucial layer of defense against network-level attacks like Border Gateway Protocol (BGP) hijacking.Ìý

But this added protection also introduces changes to how domain validation is performed—changes that every organization using digital certificates needs to understand and plan for. With MPIC already in effect and enforcement deadlines approaching, organizations need to understand how it works and how to prepare.

Why traditional validation needs reinforcement

Most certificate authorities validate domain control by checking DNS records or requesting a specific file over HTTP. But those checks usually come from a single network location. While that’s sufficient in many cases, it leaves room for attackers to exploit weaknesses in the internet’s routing infrastructure.

If someone uses tactics like BGP hijacking or DNS spoofing to reroute traffic through their own servers, they can intercept or falsify the validation response. To the CA, everything appears normal, and a certificate may be issued to the wrong entity.

MPIC closes that gap. Instead of relying on one vantage point, CAs must now validate domain control from several independent network locations. If all perspectives return consistent results, the request moves forward. If they don’t, the process halts—making it much harder for an attacker to pull off a stealthy validation hack.

How MPIC works

Under , certificate authorities issuing TLS or S/MIME certificates must validate domain control using multiple independent network perspectives. This requirement applies to both Domain Control Validation (DCV) and Certificate Authority Authorization (CAA) checks.

Here’s how it plays out: The CA starts by performing its standard validation from its primary infrastructure. It then repeats the validation from additional remote locations—each running on different networks and in different geographical regions. Only when those independent checks return consistent results can a certificate be issued.

MPIC applies to all common validation methods, including:

• DNS CNAME-based validation

• HTTP-based validation

• DNS TXT-based validation

• IP address-based validation

• ACME protocol challenges (http-01 and dns-01)Ìý

Each of these methods must produce the same result from all perspectives. If any perspective sees something different, the certificate request is flagged or denied. This redundancy helps catch and block attempts to manipulate network traffic in real time.

MPIC implementation phases and timeline

To give the industry time to adapt, the CA/Browser Forum is rolling out MPIC in phases. Early deadlines focus on testing and observability, with enforcement ramping up over time. Starting in September 2025, certificate issuance will require corroboration, aka consistent validation results from multiple independent network perspectives.

Here’s the schedule for the rollout.

In addition to the number of perspectives, the rules specify that these checks must be made from at least two distinct Regional Internet Registry (RIR) regions. MPIC also introduces a quorum model, allowing for a limited number of non-corroborating results depending on how many perspectives are used.

This phased approach helps CAs build out the required infrastructure while giving domain owners time to adjust systems and resolve edge-case issues before full enforcement begins.

Preparing your systems for multi-perspective validation

To support MPIC, you’ll need to make sure your systems can handle validation requests from multiple network locations around the world. If your infrastructure uses IP-based restrictions like allowlists, firewalls, or access control lists, you may be blocking some of those remote checks without even realizing it.

Start by verifying that your validation endpoints (like DNS records or HTTP challenge files) are accessible from outside your organization’s core network. These need to be reachable not only by your CA, but also by independent perspectives across the internet.

If you use automated certificate management tools like the ACME protocol or API-based workflows, MPIC will mostly operate behind the scenes. Still, during the testing phase (through September 14, 2025), it’s worth checking your issuance logs. Any failed validations from remote perspectives could point to misconfigurations that you’ll want to fix before enforcement kicks in.

You should also review how your load balancers and CDNs handle validation traffic. These systems must serve consistent responses—like DNS records or HTTP tokens—across all regions. If caching or propagation varies from one location to another, validation could fail when viewed from different perspectives.Ìý

Preparing for MPIC implementation

Getting ahead of MPIC means taking a few proactive steps now—before validation failures disrupt certificate issuance.

Start by auditing your current validation setup. Look for anything that could block or delay validation requests from multiple locations, like strict network controls or inconsistent DNS behavior.

Next, test your validation methods from outside your primary network. You can use distributed monitoring tools or third-party services to simulate how your systems respond to requests from different regions. For DNS-based methods, check that changes propagate reliably across all authoritative nameservers, and that your TTL settings allow for timely updates.

Need help getting MPIC-ready?

As the industry moves toward MPIC enforcement, it’s important to make sure your systems are ready to support multi-perspective validation. If you’re unsure where you stand or want to be certain you’re covered, ¶ºÒõ¹Ý can help.

Our team can provide detailed guidance on MPIC implementation and how it affects your certificate lifecycle. And with integrated DNS and certificate solutions like ¶ºÒõ¹Ý’s and , you’ll have a stronger foundation for consistent, secure validation—no matter where the checks come from.Ìý