DigiCert incident report filed in the Mozilla CA compliance tracker November 1, 2026; final internal audit and alert review due November 6, 2026
The Certificates Held, the Archive Did Not: DigiCert's Report Traces a Migration, a Missed Signal, and a Deadline Today
DigiCert's incident report, filed November 1 in Mozilla's public CA compliance tracker, confirms unauthorized read access to an internal business system holding archived customer records, and the company's own timeline is the instructive part. The chain starts on February 4, 2025, when an infrastructure migration moved the system from a VPN-restricted network segment into an externally accessible zone, carrying with it a self-registration feature meant for other products. Accounts created through that feature sat outside staff multifactor authentication and, despite having no application assigned, received read-only access to the archive. Staff spotted the external accounts on June 18, 2026, and an initial review concluded, incorrectly, that they could not reach data, classifying the problem as account creation rather than data access. A report through DigiCert's security program on June 21 moved the work forward; engineers verified the issue by June 24 and shipped an authorization fix on July 2. Investigators later established that the archive was read between June 27 and July 2. Suspicion that data had been accessed came only on October 12, working backward through retained logs; DigiCert confirmed a reportable incident on October 19 and filed its preliminary report the next day, with customer notices beginning in early November. The data was mostly names, business email addresses, phone numbers, and business addresses, plus identity documents such as passports, driver's licences, and utility bills for a small minority of accounts; DigiCert describes the affected portion as small and has not published a count. The certificate business itself was not reached: the report records no issuance, validation, or revocation activity tied to the unauthorized account, customer login credentials were not exposed, the access was read-only, and DigiCert states that active certificates remain valid and need no action. One root cause is monitoring shape: an alert on blocked access existed by July 2, while alerts on actual file access and request volumes were added only on October 15. Remediation listed as complete includes disabling self-registration, moving endpoints back to private addresses, resetting business-system passwords, a full permissions review, a penetration test, and a rule requiring security approval for network access changes. Two items fall due today, November 6: an internal audit confirming no origin server is reachable from the internet, and a final review of account-creation alerts.
Executives
A certificate authority sells audited trust, and its core systems held; what failed was an archive, a migration review that never happened, and a triage assumption nobody tested for four months. That is a governance pattern, not a vendor story. Two questions transfer directly to your own organization: does every network migration pass a security review gate, with a named approver, and when a team concludes that an exposed account cannot reach data, is that conclusion tested or assumed. DigiCert's report also shows the value of the public accountability mechanism it operates under: the full timeline, including the missed call in June, is on the public record because the CA ecosystem requires it.
CIO / CISO
Keep the customer actions proportionate, starting with the one that prevents wasted work: do not revoke or reissue certificates over this incident, since DigiCert states they are unaffected and its logs show no certificate operations tied to the account. Do identify which of your representatives appear in DigiCert records and whether any of them uploaded identity documents during validation; those individuals carry the durable risk, because a passport cannot be rotated. Brief mail and help desk teams to expect convincing messages built on real names and DigiCert branding, where the tell is any request for a password, a code, or a document upload through a link. Internally, run DigiCert's two closing checks on your own estate before their deadline passes in spirit: confirm no internal origin system is internet-reachable after migrations, and confirm that self-registration is off wherever it is not a product requirement.
Engineers
The technical lessons are specific. Network position is not authorization: the archive was treated as protected because it sat behind a VPN, and the authorization layer never independently checked whether an unassigned account should read it, so build and test authorization on the assumption that any internal system may one day be reachable. Coverage matters in monitoring design: blocked-access alerts fired while successful reads went unobserved for months, so file-access and request-volume alerting belongs on every system holding sensitive records, archives included. Finally, note the retention dependency: the June access window was established in October only because logs and audit records survived, which is the practical case for keeping them.
Everyone (non-IT)
If your name is on file with DigiCert because you handled a certificate purchase or validation for your employer, watch for polished phishing that uses your real name, role, and the DigiCert brand, and never upload an identity document or type a password through a link in such a message; open your account by typing the address yourself. If you once provided a passport or licence for a validation, be a little more alert than usual to accounts or credit applications in your name, and wait for DigiCert's individual notice, which the report says is still being prepared for people whose documents were involved. Your certificates, if you use them, need nothing.