MPIC and the Future of Domain Validation

There is a quiet change happening underneath every TLS certificate your organization requests, and most teams have not noticed it yet. The way certificate authorities confirm that you actually control your own domain has changed. It is stricter now, it runs from several places on the internet at once, and starting in 2026 it runs a lot more often.

The reason it runs more often is simple. On March 15, 2026, the maximum lifespan of a public TLS certificate dropped to 200 days, the first step in the CA/Browser Forum’s phased schedule toward a 47-day maximum by 2029. Shorter certificates mean more renewals, and many renewals trigger a fresh domain validation. So the new validation process, called Multi-Perspective Issuance Corroboration, or MPIC, is no longer a rare event you can ignore. It is something your domains will go through again and again, all year long. If your setup has a weak spot, you will hit it repeatedly.

This post explains what MPIC is, why it exists, what changed in your favor and what could create an issue, what the data says about how much this already costs organizations that get it wrong, and how to make sure none of it ever causes you an outage.

Quick Answer: What Is MPIC?

MPIC (Multi-Perspective Issuance Corroboration) requires certificate authorities to validate domain control from multiple independent network locations simultaneously, closing the BGP-hijacking gap in single-perspective checks. Mandated by CA/Browser Forum Ballot SC-067 with full enforcement from September 2025. With TLS validity dropping to 47 days by March 2029, MPIC now runs at nearly every renewal, so firewall misconfiguration and inconsistent CAA records fail on a recurring schedule.

Key Takeaways

• MPIC (Multi-Perspective Issuance Corroboration) requires a certificate authority to validate domain control from multiple independent network locations at once, closing the BGP-hijacking gap that let attackers fool single-perspective checks.
• Full enforcement started September 2025 under CA/Browser Forum Ballot SC-067, and the required number and geographic spread of perspectives keeps increasing through 2026.
• Certificate lifespans dropped to 200 days on March 15, 2026 (Ballot SC-081v3), so validation, and any weak spot in it, now recurs several times a year instead of once.
• The two failure points are narrow firewall/allowlist rules and inconsistent CAA records; both are fixable, but only if you find them before your next renewal does.
• Industry survey data below shows certificate outages are already common even before this renewal cadence takes full effect, which is why automation and clean configuration are no longer optional.

Who Should Care About MPIC

MPIC is a CA-side change, but its operational consequences land on PKI teams, DNS teams, security architects, platform engineers, and compliance teams. The two failure modes it surfaces, blocked validation perspectives and inconsistent CAA records, each require a different team to fix. At 47-day maximum certificate validity from March 2029, each unfixed failure mode produces approximately eight outage-triggering renewal failures per year per affected certificate.

Role	Why It Matters	Action Item
PKI and Certificate Teams	Own certificate renewal automation and the CLM platform that runs renewals; MPIC runs at every renewal, so any validation failure surfaces as a renewal failure; at 47-day maximum validity (SC-081v3, March 2029) each misconfiguration that triggers an MPIC failure causes approximately eight renewal outages per year per affected certificate; Keyfactor’s Digital Trust Digest (September 30, 2025) found 86 percent of organizations had at least one certificate-related outage in the prior year, before the full renewal cadence increase took effect	Deploy CertSecure Manager for automated certificate discovery and renewal that surfaces validation failures before they become outages; confirm the CLM platform’s renewal workflow uses ACME with DNS-01 or HTTP-01 and has been tested against MPIC multi-perspective checks; run a certificate inventory across cloud, on-premises, and hybrid environments using CBOM Secure to confirm all renewal paths are accounted for
DNS and Infrastructure Teams	Own CAA record management and DNS zone configuration, the second most common MPIC failure source; MPIC checks CAA records from multiple perspectives simultaneously, so a CAA record that resolves differently across authoritative name servers, a DNS propagation inconsistency, or a zone transfer gap is now detected and causes a validation failure rather than passing silently; CyberArk’s 2025 State of Machine Identity Security Report found 72 percent of organizations reported at least one certificate-related outage in 2024, many attributable to DNS configuration gaps	Audit CAA records across all authoritative name servers and confirm consistent resolution from multiple DNS vantage points; fix any zone transfer or propagation inconsistencies before the next certificate renewal cycle; ensure DNSSEC is deployed for all domains with CAA records to protect against DNS cache poisoning that could undermine MPIC’s corroboration; confirm new subdomains and cloud-provisioned domains are added to the CAA record scope before their first certificate issuance
Security Architects and Platform Teams	Own firewall and allowlist rules that may block MPIC validation traffic from CA perspective IP ranges not previously seen; MPIC means validation requests now arrive from multiple IP addresses in different geographic locations, not a single predictable source; a firewall or allowlist rule permitting only known CA IPs will block perspectives in new regions as CAs expand their MPIC coverage; the BGP hijacking research that motivated MPIC (Princeton University, USENIX Security 2018) demonstrated that single-perspective validation was compromisable in practice against major CAs	Audit firewall and allowlist rules governing inbound traffic to validation endpoints (the .well-known/acme-challenge path for HTTP-01, DNS resolver access for DNS-01); open validation endpoints to the CA’s full published perspective ranges, or move away from IP-based allowlisting for domain control validation traffic entirely; test validation from multiple geographic locations using tools that simulate MPIC perspective checks; integrate CA perspective range updates into the change management process so allowlists stay current as CAs add perspectives
Compliance Teams	MPIC compliance is now a condition of certificate issuance by all publicly trusted CAs under CA/Browser Forum Ballot SC-067; a certificate issued by a CA that did not perform MPIC correctly is potentially mis-issued; for regulated industries (PCI DSS, HIPAA, DORA, CMMC) that require valid, properly issued certificates, a renewal failure caused by an MPIC configuration problem is both an availability incident and a potential compliance finding; the compressed validity schedule (47 days by March 2029) means MPIC-related renewal failures occur with much higher frequency in non-compliant configurations	Include MPIC readiness in the quarterly compliance evidence package: confirm all certificate renewals are occurring through CLM automation, confirm CAA records are consistent and current, and confirm no firewall rules are blocking CA validation perspectives; map CA/B Forum SC-081v3 phase dates (200-day March 2026, 100-day March 2027, 47-day March 2029) to internal compliance milestones for certificate automation readiness; document MPIC as a relied-upon issuance control in applicable security control frameworks
CISOs	Certificate outages caused by MPIC configuration failures are operationally equivalent to expired certificate outages but harder to diagnose: the certificate appears valid and trusted but cannot be renewed because MPIC validation is blocked; Keyfactor’s Digital Trust Digest (September 30, 2025) found that 86 percent of organizations had at least one certificate-related outage in the prior year; the move to 200-day and eventually 47-day certificates multiplies the renewal frequency, meaning MPIC-triggered failures will surface far more often in organizations that have not fixed their validation configurations	Fund the certificate automation and CLM program as an operational risk reduction investment; require that certificate renewal automation coverage and validation failure rates are reported as board-level KPIs; evaluate PKI as a Service for private PKI infrastructure so internal CA renewal operations also benefit from automated, MPIC-compatible validation workflows; mandate that MPIC readiness is confirmed for each domain before the 100-day SC-081v3 stage in March 2027 doubles the annual renewal frequency again

The Problem MPIC Was Built to Solve

For years, a certificate authority confirmed domain control from a single vantage point. It would look up a DNS record you placed, or fetch a file you put on your server, and if the answer came back correct, it issued the certificate. That works fine until someone tampers with the path the request travels.

This is where Border Gateway Protocol (BGP) hijacking comes in. BGP is the routing system that decides how traffic moves across the internet, and it was not built with much security in mind. An attacker who can manipulate routing, or who can poison DNS responses, can quietly reroute a CA’s validation check through their own server. The CA sees a correct-looking answer and issues a certificate to the wrong party. From the CA’s side, nothing looks unusual. That is what makes the attack dangerous.

This is not just a theoretical worry. In 2018, a research team at Princeton demonstrated the attack in the real world. In a study they presented at the USENIX Security conference, titled Bamboozling Certificate Authorities with BGP, they used BGP hijacking to fool certificate authorities into validating domains they did not control, and they obtained genuine certificates for domains they did not own from several of the largest CAs of the day, including Let’s Encrypt, GoDaddy, Comodo, Symantec, and GlobalSign.

The attacks were carried out ethically, but they showed the weakness was usable in practice and not just on paper. That work led directly to multi-perspective validation. Let’s Encrypt, working with the same Princeton group, deployed an early version in 2020, and the industry later adopted the approach as MPIC.

How MPIC Actually Works

Instead of checking domain control from one place, the CA now checks from several independent network locations spread across different parts of the internet. Each location runs the same validation, whether that is a DNS lookup or an HTTP file fetch, and then the results get compared.

If every perspective agrees, validation passes and the certificate moves forward. If the perspectives disagree, say one location gets a different DNS answer or sees its request redirected, the CA treats that as a red flag and halts or flags the request. An attacker would now have to hijack routing for every vantage point at the same time, which is far harder than fooling a single check. The perspectives are deliberately placed far apart, so corroboration from genuinely distinct points on the network is what counts, not two machines sitting in the same data center.

This applies to both checks that matter at issuance: Domain Control Validation, which proves you control the domain, and Certificate Authority Authorization (CAA), the DNS record that says which CAs are allowed to issue for you, which now runs from multiple perspectives as well.

The rules come from the CA/Browser Forum, specifically Ballot SC-067, and they apply to every publicly trusted CA. Full enforcement arrived in September 2025, when CAs began requiring corroboration from at least two separate perspectives. The bar keeps rising in phases. Through 2026, CAs are increasing the number of required perspectives and requiring them to span more than one regional internet registry, so the geographic spread of the checks widens over time.

The Scale of the Problem: What the Data Shows

None of this is a solution looking for a problem. Independent survey and routing-security data from the past year show why CAs, browsers, and regulators pushed for stricter, more frequent validation in the first place.

• BGP hijacking is a routine event, not a rare one. Since the start of 2020, the internet has seen more than 1,430 recorded BGP hijacking incidents, averaging around 14 a day, according to a 2026 timeline analysis by network security vendor Anapaya. Single-perspective validation had no way to detect a hijack like this while it was happening; that exposure is the entire reason MPIC exists.
• Certificate outages are already common, before renewal frequency even doubles. Keyfactor’s Digital Trust Digest: The Automation Edition, conducted with Wakefield Research and published September 30, 2025, found that 86% of organizations suffered at least one certificate-related outage in the previous year, with nearly a third reporting outages at least once a quarter.
• Automation still has not caught up with the pace of change. CyberArk’s 2025 State of Machine Identity Security Report found that 72% of organizations reported at least one certificate-related outage in 2024, and named the industry’s shift to shorter TLS lifespans as one of security leaders’ top emerging concerns.

Put together, these numbers describe an industry that was already struggling to keep up with annual certificate renewals. MPIC does not create that struggle, but the move to 200-day, then 100-day, then 47-day certificates means the same struggle now repeats several times a year instead of once.

What Changes for You, and What Does Not

For most organizations, the good news is that MPIC happens on the CA’s side and needs no action from you. You request a certificate the way you always have, and the multi-perspective checking runs behind the scenes. If you control your domain and your DNS answers are consistent across the internet, you will not notice a thing.

The part that needs attention is narrower but real. MPIC means validation requests now arrive from multiple IP addresses in different locations, not from one predictable source. If your organization restricts access to its validation endpoints with IP allowlists or firewall rules, a check coming from an unexpected location can be blocked. When that happens, the perspectives disagree, and validation fails. Two configurations tend to cause this:

• Firewall and allowlist rules that only permit traffic from a narrow set of IPs will block the perspectives they do not recognize. You need to make sure every network endpoint involved in validation can be reached from the CA’s full range of vantage points.
• CAA records that are misconfigured, or that resolve inconsistently across different parts of the internet, will now surface as failures rather than passing quietly. Because CAA is checked from multiple perspectives too, an inconsistency that one location would have missed gets caught.

On their own, neither problem is hard to fix. The catch is timing. Under the old one-year certificates, you ran into a validation issue once a year and had plenty of time to sort it out. With 200-day certificates, and shorter ones coming, you face validation far more frequently, and a brittle setup that used to fail once now fails on a schedule. A misconfiguration that causes an outage every renewal is a much bigger problem than one you tripped over annually.

Is Your Setup MPIC-Ready? A Quick Decision Table

Use this as a fast diagnostic. Match what you see in your own environment to the closest row, then act on the recommendation before your next renewal cycle runs the check for you.

Signal in your environment	MPIC risk	What to do
Firewall or allowlist only permits a fixed, narrow set of source IPs for validation traffic	High: perspectives outside the allowed list get blocked, so validation fails intermittently	Open validation endpoints to the CA’s full published perspective ranges, or move away from IP-based allowlisting for DCV traffic
CAA record resolves differently depending on which DNS resolver or region answers	High: MPIC checks CAA from multiple vantage points and will catch the inconsistency	Audit CAA records across every authoritative name server and fix propagation or zone-transfer issues
No CAA record configured at all	Medium: validation still passes, but you have no defense-in-depth against issuance from the wrong CA	Add a CAA record scoped to the CA(s) you actually use
Domain control validation is still a manual, human-triggered step (email-based DCV, one-off file uploads)	Medium-to-high: a process that ran once a year now runs roughly every 200 days, multiplying the chances of a missed step	Automate DCV with ACME and DNS-01 or HTTP-01, tied to a certificate lifecycle management tool
Certificate inventory and renewal already run through an automated CLM platform	Low: MPIC runs transparently behind standard automated issuance	Confirm your CLM vendor’s validation method already accounts for multi-perspective checks (most ACME-based tools do)

MPIC Readiness: Requirements, Failure Modes, and Monitoring Signals

Use this table to map each MPIC readiness requirement to its validation method, the failure mode when the requirement is not met, and the monitoring signal that surfaces the failure. The CA/Browser Forum SC-067 and SC-081v3 schedules are reviewed on a quarterly cadence and the required number of MPIC perspectives continues increasing through 2026.

Requirement	Validation Method	Failure Mode	Monitoring Signal	Policy Source
Validation endpoints reachable from all CA MPIC perspective IP ranges	Test HTTP-01 validation endpoint (/.well-known/acme-challenge/) from multiple geographic locations; confirm no firewall or allowlist rules block inbound traffic from the CA’s full published perspective IP ranges; use the CA’s published MPIC perspective list if available	A perspective blocked by a firewall rule sees no response or a reject; the CA’s perspectives disagree; validation fails and certificate issuance or renewal is refused; error message typically appears as a domain validation failure rather than specifically identifying the blocked perspective	Certificate renewal failure alerts in CLM platform correlating with domain validation errors; CA error response citing validation inconsistency across perspectives; periodic test of HTTP-01 endpoint from multiple geographic vantage points showing blocked access from specific regions	CA/Browser Forum Ballot SC-067 (MPIC requirement, September 2025 enforcement); individual CA MPIC implementation documentation
CAA records resolve consistently across all DNS resolvers and regions	Query the CAA record for each domain from multiple DNS resolvers in different geographic regions; confirm the same authorized CA list is returned from all resolvers; test using public DNS resolvers in different regions (Google 8.8.8.8, Cloudflare 1.1.1.1, regional ISP resolvers); CLM platform CAA monitoring	A CAA record resolves differently from one MPIC perspective than from others; MPIC treats the inconsistency as a red flag and flags or halts issuance; the certificate renewal fails even though the CAA record appears correct from a single vantage point; DNS propagation delays and zone transfer gaps are common causes	CLM platform alert on CAA resolution inconsistency across monitored resolvers; certificate renewal failure correlating with CAA validation errors in CA logs; DNS monitoring alert on CAA record propagation failure to one or more authoritative name servers	CA/Browser Forum Ballot SC-067 (MPIC applies to CAA checks); RFC 6844 and RFC 8659 (CAA standard); CA/Browser Forum Baseline Requirements Section 3.2.2.8
Certificate renewals run through automated CLM, not manual workflows	CLM platform renewal automation coverage report; confirm percentage of certificates on automated ACME-based or protocol-based renewal; test end-to-end renewal workflow including MPIC validation pass under automation; confirm no certificates in the estate rely on manual CSR submission or email-based DCV	A manual renewal process requires human action at validation time; at 200-day validity the renewal must occur roughly every 6 months; at 47-day validity roughly every 6 weeks; a missed manual renewal step causes the certificate to expire; MPIC validation failure during a manual renewal has no automated retry or alerting	CLM platform alert on certificates approaching expiry without automated renewal configured; certificate estate audit showing percentage of certificates on manual versus automated renewal; renewal failure rate tracking per certificate population	CA/Browser Forum Ballot SC-081v3 (approved April 2025): 200 days March 2026, 100 days March 2027, 47 days March 2029; CA/Browser Forum Ballot SC-067 (MPIC, September 2025)
MPIC perspective IP ranges accounted for in firewall change management	Confirm CA’s published MPIC perspective IP ranges are tracked in the firewall change management process; confirm a process exists to update allowlists when CAs add new perspective locations; test that a newly added CA perspective IP range is added to allowlists within defined SLA	A CA adds a new MPIC perspective location; the new IP range is not added to the firewall allowlist; subsequent renewals that use the new perspective are blocked; the failure surfaces as intermittent validation failures that are difficult to correlate with the allowlist gap	CA announcement of new MPIC perspective locations; certificate renewal failure rate increase correlating with CA MPIC perspective expansion events; firewall change management log gap showing CA perspective IP ranges not updated after a CA announcement	CA/Browser Forum Ballot SC-067 (MPIC perspective requirements continue increasing through 2026); individual CA MPIC announcements and perspective IP range publications

Why the Two Changes Matter Together

Put the two changes side by side and the takeaway is clear. Validation got stricter, which is good for everyone, and it got more frequent, which raises the cost of any weak spot in how you handle it. The organizations that sail through are the ones that know where all their certificates are, renew them automatically, keep their CAA records clean and consistent, and have made sure their validation endpoints are reachable from anywhere a CA might check. The ones that struggle are the ones still tracking certificates by hand, where each renewal is a small manual event and each manual event is a chance to get blocked.

The fix is not complicated, but it does need to be deliberate. Shorter certificates reward automation and punish improvisation, and MPIC is one more reason that the gap between the two is widening.

Where MPIC Fits Into the Bigger Crypto-Agility Picture

Post-quantum migration

The same discipline that keeps MPIC from causing outages, knowing exactly where your certificates are and automating how they get replaced, is what a post-quantum migration requires too, just applied to algorithms instead of validation checks. If you have not mapped out that transition yet, our guide to PQC migration in 2026 walks through building a roadmap that survives contact with production systems, and our PQC Readiness solution page covers where most organizations are stuck. Track broader post-quantum migration planning through the PQC Center of Excellence.

Cryptographic inventory and CBOM

Both MPIC and a post-quantum migration assume you actually know which certificates, keys, and algorithms are in use across your environment, an assumption that fails for most organizations relying only on network scanning to build that picture. Our breakdown of that gap, The Cryptographic Blind Spot Hiding in Your Own Infrastructure, explains why a real Cryptographic Bill of Materials (CBOM) has to look past the network layer, into source code and build pipelines, to be trustworthy.

How Encryption Consulting Can Help

The way through MPIC and 200-day certificates is to stop treating renewals as occasional manual tasks and start running them as an automated, well-monitored process.

CertSecure Manager, our certificate lifecycle management solution, is built for exactly this environment. It discovers every certificate across your cloud, on-premises, and hybrid systems, so nothing gets caught by surprise, and it automates issuance and renewal end to end, which removes the manual steps where validation problems usually surface.

It keeps a real-time inventory with expiry and configuration details, monitors your CAA records for the kind of inconsistency MPIC will now catch, and alerts you well before anything reaches a critical state. When validation runs several times a year instead of once, that automation is the difference between a routine background process and a recurring fire drill.

For organizations that need help getting the underlying setup right, our PKI Services team can review and modernize your domain validation, CAA, and certificate issuance practices, including making sure your firewall and allowlist rules accommodate validation from multiple network perspectives, so MPIC checks never get blocked.

And if MPIC has you thinking about crypto-agility more broadly rather than just TLS certificates, CBOM Secure extends the same discovery approach to every certificate, key, and algorithm across your environment, and our Crypto-Agility solution builds the capability to change your cryptographic foundation without breaking anything, including the post-quantum transition.

If you are not sure whether your current setup is ready for more frequent validation, or you want to move off manual certificate tracking before the next round of lifespan cuts, get in touch. We can help you find the weak spots before they turn into outages.

Conclusion

MPIC is one of those security improvements that works best when you never have to think about it. It closes a real gap that let attackers fool certificate authorities through routing and DNS tricks, and it does so without asking most organizations to change anything, which is a good outcome.

The thing to watch is not MPIC itself but its timing. It arrived alongside a steep drop in certificate lifespans, and the two together mean domain validation now happens often enough that any fragile part of your process will show itself sooner rather than later. The survey data above shows that outages were already common before this change; clean CAA records, validation endpoints reachable from anywhere, and automated renewals are what keep MPIC from adding to that count.

Certificate lifespans are only going to keep shrinking. The teams that treat validation and renewal as something to automate now, rather than something to handle by hand each time, are the ones who will barely notice the next change when it comes.

This post is reviewed on a quarterly cadence given the active CA/Browser Forum SC-067 and SC-081v3 policy schedules, and immediately whenever the CA/Browser Forum updates the required number of MPIC perspectives or the certificate validity reduction timeline.

Frequently Asked Questions

What is MPIC (Multi-Perspective Issuance Corroboration)?

MPIC is a domain validation method that requires a certificate authority to confirm control of a domain from several independent network locations before issuing a certificate, instead of relying on a single vantage point. If any one perspective sees a different answer than the others, the CA treats it as a red flag and halts issuance rather than trusting a route that may have been hijacked.

When did MPIC become mandatory for certificate authorities?

The CA/Browser Forum’s Ballot SC-067 set the requirement, and full enforcement began in September 2025, when publicly trusted CAs started requiring corroboration from at least two separate network perspectives for every domain validation and CAA check. The number of required perspectives, and the geographic distance between them, continues to increase in phases through 2026.

Does MPIC affect Certificate Authority Authorization (CAA) record checks too?

Yes. CAA records, which specify which CAs are allowed to issue for a domain, are checked from the same multiple network perspectives as domain control validation. A CAA record that resolves inconsistently across regions, something a single-perspective check might have missed, now gets flagged as a validation failure.

Will MPIC slow down or complicate certificate issuance?

For most organizations, no. MPIC runs on the certificate authority’s side without requiring any change to how you request a certificate. Issuance only slows down or fails if your firewall rules block validation traffic from certain network locations, or your CAA records resolve inconsistently, both of which are fixable configuration issues rather than MPIC defects.

What is the most common cause of an MPIC validation failure?

The two most common causes are firewall or IP allowlist rules that only permit traffic from a narrow set of addresses, which blocks perspectives the CA uses, and CAA records that resolve differently depending on which DNS resolver answers. Both are configuration problems, not MPIC defects, and both are fixable with an audit of your network and DNS setup.

What is the main takeaway from MPIC and the Future of Domain Validation?

MPIC closed the BGP hijacking gap in domain validation by requiring certificate authorities to check domain control from multiple independent network locations simultaneously. It became mandatory in September 2025 under CA/Browser Forum Ballot SC-067. MPIC itself requires no action from most organizations, but the 200-day certificate validity reduction (March 2026, Ballot SC-081v3) means domain validation now runs far more frequently, and any misconfiguration in firewall rules or CAA records that MPIC catches will surface on a recurring schedule rather than once a year.

Why does MPIC matter for enterprise PKI teams?

Enterprise PKI teams must ensure two things: that their validation endpoints are reachable from the full range of IP addresses each CA uses for its MPIC perspectives, and that their CAA records resolve consistently across all DNS resolvers and regions. Keyfactor’s Digital Trust Digest (September 30, 2025) found 86 percent of organizations suffered at least one certificate-related outage in the prior year. Under the CA/Browser Forum SC-081v3 schedule (47-day maximum validity by March 2029), any misconfiguration that triggers an MPIC failure will cause a certificate renewal outage approximately eight times per year rather than once.

What risks increase if MPIC-related configurations are managed manually?

Three risk categories increase with manual management. First, firewall and allowlist drift: CA perspective IP ranges change over time; manually maintained allowlists go stale and begin blocking MPIC checks without warning. Second, CAA inconsistency: manually managed CAA records may resolve differently across authoritative name servers as zone transfers propagate; MPIC catches this inconsistency that single-perspective validation missed. Third, compounding renewal cadence: at 47-day maximum validity from March 2029, each misconfiguration that causes an MPIC failure produces a certificate expiry outage approximately eight times per year rather than once.

How does MPIC connect to certificate lifecycle management?

MPIC runs at every certificate renewal, not just at initial issuance. A CLM platform that automates certificate renewal end-to-end removes the manual steps where MPIC-related configuration problems typically surface: a human-triggered renewal that fails at an MPIC check is an outage; an automated renewal with pre-checked validation endpoints and consistent CAA records is a routine background event. CertSecure Manager monitors CAA records for the inconsistencies MPIC will catch and automates renewals so each one runs cleanly without manual intervention.

What should be refreshed quarterly for MPIC readiness?

Quarterly: verify CAA records resolve consistently across all authoritative name servers and DNS regions; confirm firewall and allowlist rules accommodate the CA’s current MPIC perspective IP ranges (these ranges change as CAs add perspectives); review certificate renewal success and failure rates for any MPIC-related validation failures; confirm certificate renewal automation coverage; and check CA/Browser Forum SC-067 and SC-081v3 for updates to the required number of MPIC perspectives and the validity reduction schedule. This post is reviewed quarterly given the active CA/Browser Forum policy schedule.