A cert expiry during a registrar transfer isn't a downtime event — it's a 5-7 day window when DNS, CAA, and cert automation all stop working simultaneously and one acquired entity in your portfolio publishes the warning page to customers.
ICANN's inter-registrar transfer policy gives the losing registrar 5 days to NACK. The seller's API key was deactivated at close. Your cutover window is now a queue of stacked transfers across 8-30 entities.
M&A handover agencies retained by the buyer's integration management office or the seller's carve-out team deal with ICANN inter-registrar transfer policy (last revised 2016) creating a 5-7 day pending window where DNS changes at the new registrar don't propagate and the seller's API key has been deactivated as part of contractual close-out so cert renewals fail mid-window, RFC 8657 ACME-CAA tightening when buyers apply portfolio-wide brand standards (DigiCert-only CAA across all acquired entities) silently breaking the seller's 3+ year-old Let's Encrypt automation on a future renewal date, and Sectigo / DigiCert OV/EV cert chain replacement during brand migrations taking 5-10 business days plus post-acquisition legal-name reconciliation delays that push issuance past the investor-deck-promised cutover milestone. Merlonix monitors every acquired-entity-attached subdomain so the registrar transfer + CAA + brand-migration exposure surfaces 30 days before the cutover-window failure mode opens.
No credit card for the trial. Cancel any time.
- Check cadence (Agency)
- 5 min
- SSL pre-expiry alert
- 30 days
- Independent DNS resolvers
- 3
- Vendors watched
- 11
Where M&A handover agencies get caught out
Three failure modes where SSL expiry creates registrar transfer window cert lapses, RFC 8657 ACME-CAA portfolio brand standards silently breaking the seller's Let's Encrypt automation, and Sectigo / DigiCert OV/EV brand-migration delays missing the investor-deck cutover milestone.
M&A handover agencies retained by the buyer's integration management office or the seller's carve-out team deal with ICANN inter-registrar transfer policy (last revised 2016) creating a 5-7 day pending window where DNS changes at the new registrar don't propagate and the seller's API key has been deactivated as part of contractual close-out so cert renewals fail mid-window, RFC 8657 ACME-CAA tightening when buyers apply portfolio-wide brand standards (DigiCert-only CAA across all acquired entities) silently breaking the seller's Let's Encrypt automation on a future renewal date, and Sectigo / DigiCert OV/EV cert chain replacement during brand migrations taking 5-10 business days plus post-acquisition legal-name reconciliation delays that push issuance past the investor-deck-promised cutover milestone and trigger per-day late penalty clauses.
ICANN's Inter-Registrar Transfer Policy (last revised 2016) requires the gaining registrar to receive a valid auth-info code (EPP authorization code) from the registrant. The losing registrar is given 5 calendar days to ACK or NACK the transfer per the policy; the gaining registrar may auto-approve after the window. During the 5-7 day pending window, the domain is in a transfer state where DNS changes at the new registrar are queued but don't propagate authoritatively until the transfer completes. The seller's existing nameservers continue serving authoritative DNS during the window. Critically, the seller's cert renewal automation — which historically pulled DNS-01 ACME challenges through the seller's registrar API — typically loses API access at the contractual close (API keys deactivated as part of access-revocation). PE-backed roll-up acquisitions stack these transfer windows across the portfolio
A PE-backed roll-up acquires 8 SMB SaaS companies in a single quarter; each company's primary domain enters a 5-7 day inter-registrar transfer window staggered across the quarter. The seller-side cert renewal automation for one acquired entity (acquired-saas-3.com) had been running on a 60-day Let's Encrypt cycle through the seller's Namecheap account using the Namecheap API for DNS-01 challenges. At the legal close (acquisition Day 0), the seller's legal team revokes the seller's API keys at Namecheap as part of standard close-out access revocation. The transfer to MarkMonitor (the buyer's institutional registrar) is initiated Day 1; ICANN policy gives the losing registrar 5 days to NACK; transfer completes Day 6. The cert renewal automation runs Day 4 of the 6-day window — the API key is dead, the DNS-01 challenge fails, the cert isn't renewed. Previous cert expires Day 4 + 26 = Day 30 of the integration window. Customers see the warning page on the acquired SaaS's production portal during a peak Q4 sales quarter
A PE-backed B2B SaaS roll-up acquires 8 SMB SaaS companies during Q3 to consolidate a vertical (let's call it field-service management for HVAC + plumbing + electrical contractors). The roll-up's integration management office (IMO) engages the agency to run the SSL + DNS + registrar handover across all 8 entities, with a target of completing the cutover window before Q4 sales-season ramps. The 8 acquired SaaS companies have heterogeneous tech stacks: 3 use AWS Route 53, 2 use Cloudflare DNS through Cloudflare Registrar, 1 uses Namecheap, 1 uses GoDaddy, 1 uses a small regional registrar. Each company's primary domain (the customer-facing SaaS portal) is being transferred to MarkMonitor — the institutional registrar that the PE firm uses across its portfolio for centralized brand-protection and DNSSEC management. The transfers are staggered: company 1's transfer starts Day 1 of the integration window, company 2's transfer starts Day 4, company 3's transfer starts Day 8, and so on. ICANN's inter-registrar transfer policy requires (a) the registrant to obtain an auth-info code (EPP authorization code) from the losing registrar, (b) the gaining registrar (MarkMonitor) to submit the transfer request to the registry, (c) the losing registrar a 5-day window to ACK or NACK the transfer, (d) auto-approval after 5 days if no NACK. In practice the window runs 5-7 calendar days depending on weekends, holiday calendars, and registrar processing speed. Company 3 (acquired-saas-3.com) was on Namecheap; the seller-side automation team at acquired-saas-3 had built a Let's Encrypt renewal pipeline using the Namecheap API for DNS-01 challenges (DNS-01 was required because the SaaS uses a wildcard cert *.acquired-saas-3.com to serve per-customer subdomains). The renewal cron runs every 60 days. At close (Day 0), the seller's legal team executes the transition services agreement (TSA) and as part of standard access revocation, the seller's Namecheap API key is rotated. The agency's cutover plan inherited the cert-renewal cron but the agency's engineer assumed the Namecheap API key was still valid (the seller's outgoing CTO had said "the cert just renews on its own"). The transfer to MarkMonitor for acquired-saas-3.com is initiated on Day 1 of the integration window. ICANN's 5-day window means the transfer is pending through Day 6. On Day 4, the cert renewal cron fires — the Namecheap API key is dead, the DNS-01 ACME challenge fails to publish the verification TXT record, Let's Encrypt rejects the renewal request. The cron logs the failure but doesn't alert (the alerting was wired to the seller's PagerDuty, which was deprovisioned at close). The previous cert was issued 56 days before close and expires on integration Day 26 (close Day 56 + 30 = Day 26 of integration). On Day 26, mid-Q4 sales season, customers of acquired-saas-3 — HVAC + plumbing contractors using the platform's mobile field-service app — start hitting cert warnings on the platform's API. The mobile app's certificate pinning rejects the expired cert outright; field technicians can't log work orders on customer sites; HVAC customer-facing technicians have to manually paper-log jobs for 3 hours until the agency engineer is paged. Discovery happens when an HVAC contractor's ops manager emails acquired-saas-3 support; support escalates; the agency engineer pulls in the IMO; resolution requires (a) requesting a new Namecheap API key from MarkMonitor (since MarkMonitor now controls the domain post-transfer), (b) re-running the DNS-01 challenge through MarkMonitor's API instead of Namecheap's (different API, different syntax), (c) installing the cert across the SaaS's 4-region production fleet. Total customer-impact window: 8 hours. Downstream consequences: (1) the IMO's portfolio-wide brand standards (PE firm's "no warning pages, ever" SLA in the post-acquisition cutover playbook) are violated; (2) the acquired-saas-3 churn rate that quarter ticks up 1.8 percentage points (one HVAC contractor cancels citing "reliability concerns post-acquisition," another delays renewal pending Q1 stability); (3) the IMO engages outside post-mortem consulting to review the cutover process across the remaining 5 entities still in transfer; (4) the agency's engagement scope expands to include "API access continuity audit" as a per-entity deliverable, billed at the agency's standard $385/hr; (5) the agency's reputation in the PE firm's peer network is at risk for the next roll-up RFP cycle.
RFC 8657 (ACME-CAA, published 2019) extends the CAA DNS record format with the "accounturi" and "validationmethods" properties — letting a CAA record bind cert issuance to a specific ACME account URI. This is widely used by enterprises to enforce that only a specific cert-management tool (e.g., a centralized cert-management platform managed by the buyer's CISO) can issue certs for the brand. When a buyer applies portfolio-wide brand standards across acquired entities — typically a DigiCert-only or Entrust-only CAA mandate driven by the buyer's CISO's institutional security policy — the seller's existing Let's Encrypt automation (which has been running successfully for 3+ years) suddenly fails on the next renewal date. The buyer's integration team applies the CAA change Day 2 of the integration window; the next LE renewal is Day 47 (still 43 days from current cert expiry); the CAA change is forgotten in the integration tracker; on Day 47 the LE renewal fails CAA; the prior cert expires Day 90; the SaaS portal goes warning-page mid-Q1
A PE firm acquires a B2B SaaS during Q4; the buyer's CISO mandates a portfolio-wide CAA tightening to DigiCert-only across all acquired entities (institutional security policy: "all production certs issued through DigiCert with EV validation, no exceptions"). The acquired SaaS's seller-side automation has been running Let's Encrypt with a 60-day renewal cycle for 3+ years; it's never failed. The buyer's integration team applies the CAA change on Day 2 of integration (CAA at the apex tightened from "CAA 0 issue letsencrypt.org" + "CAA 0 issue digicert.com" to "CAA 0 issue digicert.com" only). The CAA change task is closed in the integration tracker. The seller-side LE renewal automation runs Day 47 of integration; the ACME directory request to LE returns a successful order; the CAA pre-issuance check fails; the renewal is rejected. The renewal cron logs the failure. The integration team's LE alerts were redirected to a deprecated Slack channel during the Day 1 access cutover. Prior cert expires Day 90 of integration — mid-Q1, peak SaaS renewal season
A PE firm acquires SoftwareCo (let's call it a B2B vertical SaaS for property management — multifamily real estate operators using the platform for rent collection, work-order management, lease management). The acquisition closes mid-Q4 2025. The buyer's CISO is responsible for portfolio-wide security posture across the PE firm's 14 portfolio companies. The CISO's institutional security policy (documented in the PE firm's Master Security Standards v3.2): "all production-facing certs across portfolio companies must be issued through DigiCert with Extended Validation. No alternative CAs permitted. CAA records must reflect this policy at the registrar level. ACME automation against Let's Encrypt or other CAs is prohibited for production use." This standard is applied to acquired entities during the standard 90-day integration runbook. SoftwareCo's cert posture pre-acquisition: the seller-side platform team had built a cert-management pipeline 3 years ago using certbot against Let's Encrypt with DNS-01 challenges through Cloudflare DNS. The renewal cycle is 60 days (so renewals happen 30 days before the 90-day cert expiry, with built-in buffer). The setup has been rock-solid: 18 successful renewals in a row, no failures, no manual intervention required. Pre-acquisition CAA at softwareco.com apex: "softwareco.com. CAA 0 issue \"letsencrypt.org\"" and "softwareco.com. CAA 0 issue \"digicert.com\"" (the SaaS used DigiCert for the EV cert on the marketing site and LE for the wildcard on the customer portal). On Day 1 of integration, the buyer's integration team executes the standard access cutover playbook — including taking over the seller's Cloudflare account, rotating credentials, redirecting alerts. The seller's certbot alerts (which had been routed to the seller's ops Slack channel) are redirected to the buyer's integration Slack channel; the integration team marks the alert routing as "complete" in the integration tracker. On Day 2, the buyer's integration team applies the CAA tightening per CISO mandate: the apex CAA is updated to remove the Let's Encrypt entry. New CAA at apex: "softwareco.com. CAA 0 issue \"digicert.com\"" only. Optional ACME-CAA accounturi binding is also added: "softwareco.com. CAA 0 issue \"digicert.com; accounturi=https://acme.digicert.com/v2/acme/account/[buyer-acme-account-id]\"" per RFC 8657. The CAA change task is closed in the integration tracker. The integration team moves on to the next runbook step. No one notes that the seller-side certbot automation is still running with its prior LE configuration. On Day 47 of integration, the certbot renewal cron fires for *.portal.softwareco.com (the wildcard on the customer portal). Certbot submits the ACME order to LE's ACME directory; LE returns a successful order with authorization challenges. Certbot publishes the DNS-01 TXT record through Cloudflare. LE's pre-issuance CAA check resolves the apex CAA, finds only "issue digicert.com" with the accounturi binding to the buyer's DigiCert ACME account, and returns CAA failure (LE is not authorized to issue per the CAA policy). LE rejects the renewal request. Certbot logs the failure to its standard log file. Certbot's alert hook fires — but the alert hook's Slack webhook URL was the seller's deprecated webhook (the buyer's integration team had redirected the alerts at the receiving end, but didn't update the certbot alert-sending configuration on the application side). The alert silently fails to deliver. Certbot retries the renewal every 24 hours per its default schedule. Each retry fails. The integration team is unaware. Day 60: the seller-side renewal cycle would have renewed the cert (still 30 days of buffer remaining from prior cert). No renewal happens. Day 75: the seller-side automation team would have manually intervened (this is the team's "15-day buffer for review" point) — but the team has been transitioned out as part of the carve-out; no one is watching. Day 90: the prior cert expires. It's mid-Q1 — peak SaaS renewal season for property-management platforms because property managers do their annual software-stack budgeting in Q1. Customers hitting *.portal.softwareco.com see the cert warning. Property managers using the platform's mobile app see cert pinning failures. A property management firm with $2.4M ARR on the platform — currently in renewal discussions with the buyer's account team for a 3-year contract uplift — calls the account team to ask "what happened to your platform?" The account team escalates to the IMO. The IMO escalates to the agency. Resolution requires (a) requesting a new DigiCert OV/EV cert (the EV pathway requires legal-entity validation that takes 5 business days; the OV pathway is faster but still 1-2 business days), (b) installing the new DigiCert cert on the customer portal fleet, (c) updating the ACME automation to point to DigiCert's ACME service with the buyer's account credentials, (d) re-validating the wildcard scope. Total cert-expired window: 14 hours before the OV cert is issued and installed. Downstream consequences: (1) the property management firm pauses the 3-year renewal discussion; the deal slips from Q1 to Q2, at risk of competitive displacement; (2) the IMO's post-mortem identifies CAA-tightening as a systematic gap in the integration runbook; the runbook is updated to require "verify all ACME automation in scope before applying CAA changes"; (3) the agency's engagement scope expands to include a "pre-CAA-change ACME automation audit" deliverable on the remaining portfolio integrations; (4) the buyer's CISO is briefed; the CISO's next portfolio-wide security review reduces confidence in the CISO's portfolio-cert-management roadmap; (5) the agency's engagement contract's indemnity clause is reviewed by outside counsel for buyer-side recourse.
Sectigo and DigiCert offer Organization Validation (OV) and Extended Validation (EV) cert products. OV requires verification of the legal entity's registered name + address against a recognized business registry (typically the secretary of state where the entity is incorporated, plus a Dun & Bradstreet or similar third-party verification). EV adds verification of physical operational existence and authorization of the cert requester. OV processing typically takes 1-3 business days; EV typically takes 5-10 business days; both can extend further if back-and-forth on documentation is required. Brand migrations during M&A — renaming the acquired entity, consolidating customer-facing subdomains under the buyer's brand — typically require new wildcard certs issued to the new brand's legal entity. Post-acquisition, the legal-entity name often doesn't match what was filed with the secretary of state at incorporation, which extends OV/EV processing further
A corporate-development team plans a brand migration cutover for an acquired SaaS over a 30-day timeline (the SaaS's customer-facing brand is being migrated from "AcquiredCo" to "BuyerBrand SaaS Suite — formerly AcquiredCo"). New customer-facing domains are buyerbrand.com/saas and saas.buyerbrand.com. The new wildcard EV cert (*.saas.buyerbrand.com) is ordered from DigiCert on Day 1 of the cutover timeline. DigiCert's EV process requires legal-entity validation. The buyer's legal-entity name post-acquisition (BuyerCo Holdings LLC d/b/a BuyerBrand) doesn't match what was filed with the Delaware secretary of state at incorporation (BuyerCo Holdings LLC, no DBA filing). DigiCert's validation team flags the discrepancy on Day 3. The buyer's legal team has to file a DBA registration with Delaware (3 business days) and provide updated registry documentation to DigiCert (1 business day for DigiCert review). Cert issuance happens Day 13. Cutover slips 13 days. Investor-deck-promised "brand integration complete by end of Q2" milestone is missed
A corporate-development team at a strategic acquirer (mid-cap public company, healthtech vertical) acquires a smaller B2B SaaS (let's call it AcquiredCo, a niche revenue-cycle-management platform for outpatient clinics). The acquisition is a strategic bolt-on; the corp-dev team's investor-relations narrative emphasizes "fast brand integration" and "unified customer experience by end of Q2." The investor deck circulated to analysts on the acquisition announcement quarter-end call commits to a 30-day brand-migration cutover for the customer-facing platform: AcquiredCo's portal is being rebranded to BuyerBrand SaaS Suite — formerly AcquiredCo, hosted on saas.buyerbrand.com (replacing portal.acquiredco.com). The agency is engaged to run the SSL + DNS + cert-chain replacement during the cutover. The cutover plan: Day 1: order new wildcard EV cert *.saas.buyerbrand.com from DigiCert; Day 7: DNS apex preparation at buyerbrand.com (CAA, MX, TXT); Day 14: install cert on the customer-portal infrastructure (multi-region, AWS ALB-fronted); Day 21: HTTP redirects from portal.acquiredco.com to saas.buyerbrand.com; Day 28: customer communication blast announcing the migration; Day 30: cutover complete, milestone signed off. The agency's engineer initiates the DigiCert EV cert order on Day 1. DigiCert's EV process requires (a) legal-entity validation against the secretary of state in the state of incorporation, (b) physical-existence verification (callback to a verified business phone, sometimes a site visit), (c) authorization verification (the cert requester is verified as authorized by an officer of the legal entity). The buyer's legal-entity name on the cert order: "BuyerCo Holdings LLC d/b/a BuyerBrand." The DBA assertion in the cert subject is required because BuyerBrand is the consumer-facing brand and BuyerCo Holdings LLC is the registered legal entity. DigiCert's validation team queries the Delaware secretary of state on Day 2: the registry shows BuyerCo Holdings LLC with no DBA registration. DigiCert flags the discrepancy back to the agency on Day 3 — the EV cert can't be issued with a DBA assertion that isn't backed by a registered DBA filing. The agency escalates to the corp-dev team. The corp-dev team escalates to the buyer's legal team. The buyer's legal team initially says "we don't need a DBA, just issue the cert to BuyerCo Holdings LLC" — but the corp-dev team pushes back because the customer-facing brand (BuyerBrand SaaS Suite) needs to appear in the cert subject for customer-trust-signal reasons (specifically, healthcare RCM customers' compliance teams scan cert subjects as part of vendor risk assessments and want the consumer brand to match the contractual entity). The buyer's legal team agrees to file a DBA registration with Delaware. Delaware DBA filings take 3 business days standard processing (or 1 business day with expedited fee). The buyer's legal team files Day 4; expedited; filing confirmed Day 5. The buyer's legal team provides the filing confirmation + updated registry documentation to DigiCert on Day 6. DigiCert's validation team takes 1 business day to re-validate (Day 7). DigiCert then proceeds with physical-existence verification: the verified business phone for BuyerCo Holdings LLC is called Day 8; the call goes to the corp-dev team's shared voicemail; DigiCert's validation team logs "callback pending." The corp-dev team returns the call Day 9; DigiCert's validation team is in a different timezone; the call is missed; rescheduled for Day 10. Day 10: callback completes; DigiCert proceeds with authorization verification (the cert requester — the agency engineer — needs to be authorized in writing by an officer of BuyerCo Holdings LLC); the buyer's general counsel signs the authorization Day 11; DigiCert reviews Day 12; cert is issued Day 13. The agency installs the cert Day 13 — already 12 days behind the original cutover plan. The cutover plan's subsequent steps (DNS apex prep Day 14, redirects Day 21, customer communication Day 28, milestone Day 30) all slip. The corp-dev team's investor-relations narrative — "brand integration complete by end of Q2" — is at risk. The end-of-Q2 milestone date is fixed (it's tied to the next quarterly earnings call). The corp-dev team and the agency triage: option A (slip the milestone, update IR narrative on the next earnings call) is unacceptable to the corp-dev team because the IR narrative was central to the acquisition's investor pitch; option B (compress the remaining cutover steps into 13 days) is risky but executable. The team chooses option B. The customer communication blast goes out Day 28 as originally planned, even though the cutover is partially complete (DNS prep is done, but redirects from the old domain are not fully in place). During a brief window on Day 29 between the customer comms blast and the redirect deployment, customers visiting portal.acquiredco.com see the cert that was issued to portal.acquiredco.com (still valid) but the platform's landing page now references "BuyerBrand SaaS Suite" while the cert subject still says "AcquiredCo Inc." Customer compliance teams scan and flag the mismatch. Two healthcare RCM customers (each with $1.2M ARR) escalate vendor-risk concerns to their procurement teams. The agency's engagement contract with the buyer includes a per-day late penalty clause (a common clause in M&A handover engagements with hard milestone dates): $25,000 per business day past the contractual cutover date. The cutover slipped 13 days; 9 of those are business days; the penalty is $225,000. The agency disputes the penalty under the contract's force-majeure clause (legal-name reconciliation outside the agency's control); negotiation extends the dispute over 60 days; settled at $112,500 (50%). The agency's reputation in the corp-dev team's peer network — strategic acquirers in the healthtech vertical — is affected; the agency is not invited to bid on the corp-dev team's next acquisition cutover.
How it works
SSL and DNS monitoring for M&A handover agencies across the 5-7 day ICANN inter-registrar transfer window where DNS doesn't propagate and seller-side cert automation lost API access at close, RFC 8657 ACME-CAA portfolio brand-standard rollouts that silently break the seller's Let's Encrypt automation on the next renewal date, and Sectigo / DigiCert OV/EV brand-migration cert chain replacement extended by post-acquisition legal-name reconciliation.
Merlonix monitors SSL expiry and DNS integrity across every acquired-entity-attached subdomain — portal.* (customer SaaS portal), app.* (mobile/web app), api.* (programmatic API), sso.* (federated identity) — and catches cert expiry before any registrar transfer window can stack against a pending renewal during the 5-7 day pending state, before any portfolio-wide CAA tightening can silently break the seller's Let's Encrypt automation on a future renewal date, and before any brand-migration cutover slip can trigger per-day late penalty clauses tied to investor-deck-promised milestones. Each entity gets independent monitoring because each one carries independent registrar transfer state, CAA state, and cert-renewal-automation health that the integration team inherited from the seller and that flows back to the agency under the engagement's cutover SLA.
01
Add every acquired-entity-attached subdomain — portal.*, app.*, api.*, sso.*, plus the entity's primary marketing domain — across the portfolio of 8-30 entities with DNS TXT verification that catches cert expiry and registrar transfer + CAA + brand-migration exposure 30 days before the cutover-window failure mode opens
Verify ownership with a DNS TXT record on each acquired entity's apex. All entity-attached subdomains under that apex — portal.* (customer-facing SaaS portal), app.* (mobile/web app), api.* (programmatic API), sso.* (federated identity) — are added without additional verification per entity. Monitoring every acquired-entity subdomain catches cert expiry 30 days before the failure window opens — well before any registrar transfer window can stack against a pending renewal, well before any CAA tightening can silently break the seller's Let's Encrypt automation, and well before any brand-migration cutover slip can trigger per-day late penalty clauses. Under two minutes per entity; portfolio of 30 entities adds in under an hour.
02
CAA inheritance monitoring across portfolio brand-standards rollouts and registrar nameserver changes — surfacing the RFC 8657 ACME-CAA tightening that silently breaks the seller's Let's Encrypt automation on the next renewal date
Three independent DNS resolvers check every CNAME and CAA record on every monitoring interval, walking the CAA inheritance chain from the apex up. When the buyer's integration team applies a portfolio-wide CAA tightening (typically driven by the buyer's CISO's institutional security policy: DigiCert-only or Entrust-only across all acquired entities, often with RFC 8657 accounturi binding to a centralized ACME account), the change is detected in the first check cycle — well before the seller's certbot or acme.sh renewal cron fires on its next scheduled renewal and silently fails CAA. Particularly important during the 5-7 day inter-registrar transfer window when nameservers shift between the seller's and the buyer's institutional registrar (MarkMonitor, Cloudflare Registrar, or similar).
03
SSL monitoring 30 days before expiry across the portfolio of acquired entities — independent per-entity checks because each one has independent registrar transfer state, CAA state, and cert-renewal-automation health that the integration team inherited from the seller
Full SSL chain validation on every acquired-entity subdomain. Independent checks per-entity catch cert expiry 30 days before the failure window opens — enough time to verify the cert renewal automation still has API access at the registrar (the seller's API key may have been rotated at close), the CAA state still permits the issuing CA, and the cert is being installed on the buyer's post-cutover infrastructure (not just the seller's pre-cutover infrastructure). The 30-day lead time covers both the 60-90 day Let's Encrypt cycle and the worst-case Sectigo / DigiCert OV (1-3 business days) or EV (5-10 business days) issuance cycle if a brand migration requires a new wildcard cert under the buyer's legal entity.
04
Vendor status for the major registrars (MarkMonitor, Cloudflare Registrar, Namecheap, GoDaddy, Network Solutions), DNS providers (AWS Route 53, Cloudflare DNS), the public CAs (DigiCert, Sectigo, Entrust, Let's Encrypt), and the ICANN inter-registrar transfer status page — to distinguish vendor-side incidents from per-entity SSL configuration failures during the cutover window
Merlonix monitors the institutional registrars used in M&A handover (MarkMonitor for PE-backed roll-ups, Cloudflare Registrar for tech-vertical bolt-ons, Namecheap and GoDaddy for SMB-side seller registrars, Network Solutions for legacy enterprise), the major DNS providers (AWS Route 53, Cloudflare DNS), the public CAs (DigiCert, Sectigo, Entrust, Let's Encrypt), and the ICANN inter-registrar transfer status page alongside each entity's cert state — so when the ICANN transfer queue is congested or DigiCert's OV/EV processing is slow during a regulatory rush, you see the vendor event clearly rather than spending hours investigating whether a per-entity cutover is misconfigured.
What the numbers mean for M&A handover agencies
Monitoring built for M&A handover agencies where one portfolio engagement means a 5-7 day inter-registrar transfer window stacked across 8-30 acquired entities, an RFC 8657 ACME-CAA portfolio brand-standard rollout that the integration team applies on Day 2 and forgets, and a Sectigo / DigiCert OV/EV brand-migration cert chain replacement gated by post-acquisition legal-name reconciliation with the secretary of state — each with independent cutover-window implications when a cert silently expires and the agency's engagement contract's per-day late penalty clause triggers.
M&A handover agencies running the SSL + DNS + registrar handover during the cutover window need monitoring that recognizes each acquired entity has independent registrar transfer state, CAA state, and cert-renewal-automation health inherited from the seller — because the registrar-transfer failure is silent (the seller's API key was deactivated mid-window; the renewal cron logs the failure but the alerts route to a deprovisioned PagerDuty), the CAA-tightening failure is silent (the LE renewal happens 47 days after the CAA change; the integration team has long since closed the CAA task in the tracker), and the brand-migration delay is silent until the investor-deck milestone date is days away (DigiCert's OV/EV processing extends through legal-entity name reconciliation; the cutover slips 13 days; the per-day late penalty triggers).
< 10 min
Time from DNS change to alert — catches RFC 8657 ACME-CAA tightening introduced by the buyer's integration team during the standard 90-day post-close runbook (DigiCert-only or Entrust-only CAA across the portfolio, often with accounturi binding to a centralized ACME account) that silently breaks the seller's Let's Encrypt automation on the next renewal date, plus registrar nameserver changes during the 5-7 day inter-registrar transfer window
30 days
SSL expiry warning lead time — enough time to verify the cert renewal automation still has API access at the registrar (the seller's API key may have been rotated at close), the CAA state still permits the issuing CA, and to absorb worst-case Sectigo / DigiCert OV (1-3 business days) or EV (5-10 business days) issuance cycle if a brand migration requires a new wildcard cert under the buyer's legal entity post-DBA-filing
11 vendors
Upstream services monitored — MarkMonitor, Cloudflare Registrar, Namecheap, GoDaddy, Network Solutions, AWS Route 53, Cloudflare DNS, DigiCert, Sectigo, Entrust, Let's Encrypt, plus the ICANN inter-registrar transfer status page. Distinguishes a vendor-side incident from a per-entity cert misconfiguration during the cutover window
200 assets
Maximum monitored domains on the Agency plan — covers a portfolio of 30 acquired entities with portal.*, app.*, api.*, sso.*, and apex per entity (typical PE roll-up runbook), plus any additional brand-migration target subdomains during the cutover. Multi-quarter staggered acquisition cohorts and parallel carve-out engagements for the seller side are absorbed without per-domain fees
Pricing
Flat monthly fee. Every acquired-entity subdomain, every brand-migration target, every cutover-window asset included.
No per-entity charges. No per-cohort fees. Pick the tier that fits your portfolio of acquired entities and monitor every cutover-window subdomain (portal.*, app.*, api.*, sso.*) under each entity's apex without billing surprises.
Starter
For solo handover engineers or two-person carve-out shops running a single acquired entity's portal, app, API, and SSO subdomains under one apex during a single-quarter cutover window.
$29/ month
- 10 monitored assets
- 1 seat
- 15-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Team
For M&A handover agencies managing 5-10 acquired entities in a single PE-backed roll-up cohort with separate portal.*, app.*, api.*, and sso.* subdomains per entity, plus the entity's primary marketing domain across the cutover window.
$79/ month
- 50 monitored assets
- 5 seats
- 10-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Agency
For agencies running portfolio-scale handover engagements covering 8-30 acquired entities across multiple PE roll-up cohorts, corporate-development bolt-ons, and seller-side carve-out engagements running in parallel — with brand-migration target subdomains added per entity as the cutover progresses.
$199/ month
- 200 monitored assets
- 15 seats
- 5-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Know when an acquired entity's portal is approaching cert expiry mid-registrar transfer — 30 days before the seller's deactivated API key, the buyer's portfolio CAA tightening, or a Sectigo / DigiCert OV/EV brand-migration delay can publish the warning page to customers mid-cutover.
Add your first acquired-entity subdomain in under two minutes. Customer portals, mobile/web apps, programmatic APIs, and SSO endpoints across every entity in the cohort are monitored from the same dashboard. 14-day trial, no card required.