The DigiCert Breach Explained: How an Archived System Exposed Identity Documents, and What to Do About It

Nobody broke down the door here. A private room quietly became reachable from the street, strangers could sign themselves in at the front desk, and a weakness in the permissions let them read the old files stored inside.

Today is November 6, 2026, and this story matters right now because DigiCert, one of the best-known certificate authorities, is notifying customers about a breach of archived records. Those records include business contact details and, in some cases, identity documents such as passports and driving licences. The company's own list of follow-up work also carries deadlines of today.

If you are a DigiCert customer, you have a short list of practical jobs to do. If you are not, this incident is still worth your time, because the same pattern can sit inside almost any company: an older internal tool, a network change, and a set of assumptions that nobody has checked for years.

This guide explains what happened in plain language, separates what is known from what is not, and walks through two worked examples. In the first, a security lead called Rohit handles the response at a customer. In the second, Rohit tests one of the company's own archives for the same kind of failure.

A short glossary before we start

A few terms come up often, so here they are in simple words.

• Certificate authority: an organisation that verifies who you are and issues the digital certificates that let websites and software prove their identity.
• Identity verification: the checks a provider performs before trusting a person or company. This can involve submitting documents.
• VPN: a private, encrypted connection. Many internal systems can only be reached through one.
• Multifactor authentication (MFA): a login that needs a second proof, such as a phone approval, on top of a password.
• Authentication: proving who you are.
• Authorisation: deciding what you are allowed to see or do once your identity is known.

Keep the last two in mind. They are the heart of this story.

What happened, in order

DigiCert's incident report was published through Mozilla's public compliance tracker for certificate authorities. Together with the customer notification, it gives this sequence.

Date	What happened
4 February 2025	A migration made a system previously restricted by a VPN externally accessible
June 2026	DigiCert discovered unauthorised accounts and initially concluded they could not access customer information
Date not stated	A report through its managed security research programme raised concerns about external account creation, and security fixes followed
27 June to 2 July 2026	The period of unauthorised access later confirmed
19 October 2026	Further examination confirmed that unauthorised access to customer records had taken place
6 November 2026	Deadline listed for the external-exposure audit and the final account-alerting review

Notice the gap between the migration and the discovery. The system changed in February 2025, and the accounts were found in June 2026. Also notice the gap between finding the accounts and confirming what they read. That second gap is one of the most useful lessons in the whole report.

How three small things became one big problem

No single failure tells the story. Three conditions lined up.

First, the network barrier disappeared. A system that had been protected by a VPN became reachable from outside during a migration. People often treat a VPN as the thing that makes an internal tool safe. Once it is gone, every assumption built on top of it is exposed.

Second, outsiders could create accounts. A self-registration feature let people from outside make accounts. These accounts did not have the MFA that staff were required to use.

Third, a permission weakness did the rest. Those new accounts had no application assignments. In other words, on paper they should have had nothing. An authorisation weakness still gave them read access to archived records.

Think of an office building. The building used to sit behind a locked gate (the VPN). A renovation removed the gate. The front desk would give a visitor badge to anybody who asked (self-registration). The badge was not meant to open any door, but one storeroom's lock accepted any badge at all (the authorisation weakness).

Each part alone might look survivable. Together, they exposed the files.

Authentication is not authorisation

This is the central lesson, and it applies far beyond this incident.

Being able to log in proves very little. It tells a system that an account exists and that someone holds its credentials. It says nothing about whether that account should be able to pull a passport scan from an archive.

OWASP, the well-known application security project, separates the two functions clearly in its authorisation guidance. Authentication establishes identity. Authorisation decides which resources and actions that identity may access. OWASP recommends three habits:

• Deny access by default.
• Apply least privilege, meaning each account gets only what it truly needs.
• Check permissions on every request.

Applied to an archive, those principles mean a brand new account should receive no customer records until an explicit, justified permission grants them. No role or application assignment should produce a refusal, never a fallback permission.

To be fair and exact, that is an architectural implication of OWASP's guidance. It is not an additional finding about how DigiCert built its system.

Why the first investigation missed it

DigiCert found the accounts in June 2026 and first concluded that they could not reach customer information. Later work showed otherwise.

This is very easy to do, and worth understanding. An administrator opens a management screen, sees an account with no roles, and reasonably concludes that it can do nothing. But that screen shows labels. It does not show what the application will actually return when the account asks for something. An account that appears unassigned may still reach endpoints whose access checks behave differently from the central account-management interface.

So an unexpected account should prompt three questions:

1. What are its effective permissions, meaning what can it really do?
2. What sessions did it open?
3. Which resources did it actually request?

There is a second lesson in the same sequence. Closing an access route and finding out what happened before you closed it are two separate tasks. DigiCert introduced fixes, but those fixes did not immediately establish whether records had already been accessed. Only the examination on 19 October confirmed access between 27 June and 2 July.

Whenever you fix a permissions failure, remember to look backwards. Was this same failure used before the fix, including by accounts or sessions that already existed?

What was exposed, and why identity documents change everything

The exposed information included names, business email addresses, telephone numbers and business addresses. Some records also contained documents submitted for identity verification.

DigiCert says it is still reviewing identification documents to determine who was affected, and will notify those individuals after that review is complete.

For the people involved, the difference is large. Someone whose work email sits in a record has one set of concerns. Someone whose passport scan was also available has a very different set. You can change an email address far more easily than the details printed on a passport.

Brandefense's assessment points to the potential for targeted impersonation, including messages that exploit an existing relationship with a certificate provider. It recommends identifying which representatives supplied verification documents and warning them about suspicious follow-up requests.

Here is a plausible example, and it is only hypothetical. A message claims that your organisation must repeat its identity verification to avoid disruption to its certificates. It might sound convincing, because it could include accurate names, contact details and knowledge of your supplier.

These are possible risks and sensible precautions. They do not show that criminals have used this breach for fraud.

What DigiCert says was not affected

This part is important, and it deserves as much care as the bad news.

DigiCert says its certificate authority services, CertCentral and DigiCert ONE were unaffected. It says customer login credentials and issued certificates remain secure, and that customers do not need to replace active certificates because of this incident.

The company also says the unauthorised account could not modify records, approve validations or issue certificates, and that its review found no associated certificate issuance, validation or revocation activity.

So the immediate response for customers is about exposed information and the people behind it. A rushed certificate replacement is not called for by this incident, according to the company's statement.

There is a useful way to think about this. Breach impact has separate dimensions:

• Confidentiality asks whether information was disclosed.
• Integrity asks whether records or processes were altered.

A restriction on write access can protect integrity and still leave sensitive information exposed. Read-only access can sound harmless, but OWASP lists unauthorised reading as a potential consequence of broken access control, with severity depending on how sensitive the resources are. When read access reaches personal records, "read-only" is no comfort at all.

What DigiCert has changed

The incident report lists these corrective measures:

• Self-registration disabled.
• Private endpoints.
• Password resets for business-system users.
• Additional monitoring.
• A permissions review.

An external-exposure audit and a final account-alerting review were listed as ongoing, with deadlines of 6 November 2026.

The bigger architectural point lines up with NIST's Zero Trust Architecture guidance. NIST says a system or account should receive no implicit trust solely because of its network location or ownership. Protection should centre on resources and explicit access decisions.

That gives every organisation a simple and slightly uncomfortable test:

Would this application still refuse an unauthorised request if a firewall rule, routing change or migration unexpectedly made it reachable?

Network restrictions are still useful. They just should not be the only thing holding the door shut.

What we still do not know

Honest reporting means listing the gaps as well.

• The public disclosure gives no total for affected people, organisations or identity documents.
• Independent coverage by Cybersixt notes that the account's operator has not been publicly identified.
• Without those numbers, a description such as "a small proportion of archived data" cannot tell us how many people need support, or how sensitive each person's exposure was.

Be careful with any headline that states a scale. For now, that number is not public.

Worked example 1: Rohit responds at a customer

Now let us follow a fictional company. Acme is a mid-sized firm that buys certificates from a provider. Rohit, its security lead, receives the news on a Friday morning. Everything below is an illustration, including every name and address.

Step 1: Do not start with the certificates

Rohit's first instinct is to check the certificates, but the provider's statement says active certificates do not need replacing. Replacing them in a hurry would create risk and work without addressing the real concern. Rohit writes down the actual question for the day: which of our people had their information exposed?

Step 2: Build a list of people

Rohit asks the certificate-management team who has ever dealt with the provider for Acme. Past employees count too, since archives remember people who left long ago.

The list is simple and answers three questions per person:

Name         Role              Gave contact details   Gave identity document
A. Sample    Network engineer  yes                    unknown
B. Sample    Finance manager   yes                    yes (from old emails)
C. Sample    Former employee   yes                    unknown

The word "unknown" is honest and useful. It becomes the next set of questions.

Step 3: Ask the supplier precise questions

A vague email gets a vague answer. Rohit sends these questions through the established account contact:

1. Which of our people and which documents were involved?
2. What evidence establishes that they were accessed?
3. Do you expect to send further individual notifications?

Then Rohit records each answer with a date, so that the team can tell later what was known and when.

Step 4: Bring in privacy and HR

Technical assurance about certificates should not hide the needs of staff. Rohit brings together the certificate team, security and privacy colleagues. For the people on the list, the question is personal: "Was my passport in there?" They deserve a direct answer as soon as one exists, and a clear "we do not know yet" until then.

Step 5: Warn people before an attacker reaches them

Rohit sends a short note to everyone on the list:

You may be contacted about our certificate provider.
Do not upload identity documents, click links or confirm details
because of a message, even one that uses accurate names.
Report it to [email protected]. We will verify it through a
known contact.

This is the most important human step in the whole response. Any instruction to upload replacement identity documents should be verified independently, through a known contact or an authenticated service.

Step 6: Do the routine hygiene, and label it correctly

Rohit reviews the account's users and API keys on the provider's portal, removing a former employee's access. This is routine security hygiene. It should not be described as a response to compromised credentials, because the provider says those remain secure. Precise wording stops rumours inside the company.

Step 7: Keep the case open

The provider is still reviewing identity documents, so the case stays open. Rohit schedules a check every week and closes it only when the supplier's notifications have finished and every person on the list has received an answer.

Worked example 2: Rohit tests Acme's own archive

The more valuable question comes next. Could this happen to us? Rohit picks an old internal tool, archive.example.com, which holds scanned supplier contracts. Staff reach it over a VPN. Everyone assumes it is safe. Run tests like these only on systems you own or have permission to test.

Step 1: List what you keep, and why

Before testing anything, Rohit answers four questions about the documents:

• Why were they collected?
• Where do copies remain?
• Who can retrieve them?
• How is access monitored?

The first question often finds the quickest win. If nobody can explain why a scanned document is still kept, that is worth raising with the privacy team.

Step 2: Find every way to create an account

Rohit looks for sign-up pages, invitation links and single sign-on settings. A self-registration feature can sit forgotten for years inside older software. Rohit also confirms whether the same MFA rule applies to every account, including those not created by staff.

Step 3: Pretend the network barrier has gone

From a test network that bypasses the VPN path, in an approved test environment, Rohit tries the application directly. Then, with a new account that has no role at all, Rohit requests a record:

curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer REPLACE_WITH_TEST_TOKEN" \
  https://archive.example.com/api/documents/1001

The answer Rohit wants is 401 or 403, meaning the request was refused. A 200 means the account received the document, and that is a finding even if the account "has no permissions" on the admin screen.

Step 4: Test every door, not just the main one

Permission checks can differ between pages, so Rohit repeats the request across search, export, download and API endpoints. Web interfaces may hide a button while the server behind it still answers. The test must always ask the server.

Step 5: Make refusal the default

Rohit asks the developers to confirm the logic follows this shape. This is a simple illustration of deny-by-default, not any real product's code:

def can_read(user, document):
    if user is None:
        return False
    # No explicit grant means no access. There is no fallback.
    return document.id in user.explicit_grants

The important part is what is missing. There is no "otherwise allow" branch, and an account with no assignments ends up with no records.

Step 6: Watch for the signal that matters

Rohit adds alerts for new external accounts and for any account that reads many documents shortly after being created. An alert on a new account is useful only if somebody then checks what that account actually did.

Step 7: Add migrations to the checklist

Finally, Rohit changes the migration review. Previously it asked, "Does the system work after the move?" Now it also asks, "What can be reached that could not be reached before, and how do those services behave?" Assumptions about who can reach a system can outlive the infrastructure they were based on, and older business tools are where that happens most.

The wider lesson for security leaders

Archives feel dull, so they tend to receive less attention than live systems. But the data inside is often older, less reviewed and just as sensitive. An archive's reduced operational visibility should not reduce the protection applied to the information it contains.

Look at the whole life of a verification document, from collection to deletion. Decide why it is collected, where copies stay, who can retrieve it and how access is monitored. Ask those questions before a migration forces them on you.

Conclusion

The DigiCert incident is not a story about certificates being forged. By the company's account, certificate operations remained secure. It is a story about a system that became reachable, accounts that should have seen nothing, and read access that reached sensitive records. If you are a customer, find out which people are affected, warn them, and verify every unexpected request through a known channel. If you are anyone else, test your archives on the assumption that the network barrier has already gone, because one day a migration might make that true.

Merits

• Customers have clear, practical steps that do not require replacing active certificates.
• The public incident report gives every team a real case to learn from.
• The test described here is cheap and works for any old internal tool.
• Reviewing stored documents can reduce future risk by removing data no longer needed.
• Treating authorisation as a separate control protects systems even when network settings change.

Demerits

• Affected people may wait for answers while the document review continues.
• The public numbers are missing, so true scale cannot be judged yet.
• Reviewing old archives takes time, and older tools can be poorly documented.
• Permission testing across every endpoint needs skill and approved test environments.
• Warnings to staff can cause worry when facts are still incomplete.

Caution

This article is educational and is based on public reporting available at the time of writing, so details may change as the investigation continues. Acme, Rohit, the sample staff, the addresses, the token and the code are fictional placeholders and must be replaced with your own values. Test only systems you own or are authorised to test, and verify claims against DigiCert's own notices and your legal or privacy advisers before relying on them.

Frequently asked questions

• What happened in the DigiCert breach? — A migration on 4 February 2025 made a VPN-restricted system externally accessible, outsiders could self-register accounts, and an authorisation weakness gave those accounts read access to archived records.
• What data was exposed? — Names, business email addresses, telephone numbers and business addresses, plus identity documents in some records, such as passports and driving licences.
• Do I need to replace my DigiCert certificates? — DigiCert says customers need not replace active certificates because of this incident, and that issued certificates and login credentials remain secure.
• Were CertCentral and DigiCert ONE affected? — DigiCert says its certificate authority services, CertCentral and DigiCert ONE were unaffected, and its review found no associated issuance, validation or revocation activity.
• How many people were affected? — The public disclosure gives no total for people, organisations or identity documents, and DigiCert says it is still reviewing identification documents.
• What should affected customers do now? — Identify who supplied information, check whether identity documents were submitted, and verify unexpected messages through established channels.
• What is the difference between authentication and authorisation? — Authentication proves who you are, while authorisation decides what you may access, so a successful login alone should never unlock sensitive records.
• How can I test my own archive for this problem? — In an authorised test, create an account with no role and request records directly from every endpoint; anything other than a refusal is a finding.

Tags

#DigiCert #DataBreach #IdentityDocuments #AccessControl #Authorisation #IncidentResponse #ZeroTrust #OWASP #PrivacyRisk #CyberSecurity