Notifications
Clear all
Topic starter
25/06/2026 10:39 pm
TL;DR: CAB Forum validation rules removed two legacy domain-validation methods that had allowed weaker proof of control for publicly trusted certificates, and continued use now risks misissuance, revocation, or distrust on short notice, according to DigiCert. The change makes certificate governance less about preserving familiar workflows and more about proving technical control with methods that withstand scrutiny.
NHIMG editorial — based on content published by DigiCert: New CAB Forum Validation Rules Go Into Effect Today
Questions worth separating out
Q: What breaks when certificate validation relies on weak proof of domain control?
A: The trust model breaks because the certificate may be issued to an applicant that cannot actually prove control of the domain.
Q: When should certificate teams replace older validation methods with stricter ones?
A: They should replace older methods as soon as policy changes or forum rules stop recognising them as approved proof of control.
Q: How do certificate authorities know whether their issuance process is still compliant?
A: They need a method-level inventory that maps each issuance path to the current approved validation standard.
Practitioner guidance
- Map every certificate to its validation method Build an inventory that links each public certificate to the exact domain-validation method used, the approving CA, and the renewal path.
- Retire validation methods that no longer prove technical control Remove any issuance workflow that depends on attestation letters, loosely verified third-party data, or non-technical assertions of ownership.
- Tie certificate renewal to validation evidence review Do not assume a previously acceptable proof method remains acceptable at renewal.
What's in the full article
DigiCert's full blog post covers the operational detail this post intentionally leaves for the source:
- The specific CAB Forum ballots and baseline requirement changes that drove the validation rule update.
- The background on why methods #1 and #5 were considered too loose for publicly trusted issuance.
- The historical context around earlier attempts to tighten validation and remove the “any other method” loophole.
- The discussion of what certificate holders should ask their CA when validating current certificates.
👉 Read DigiCert's analysis of the CAB Forum validation rule changes →
CAB Forum validation rules: what do certificate teams need to change?
Explore further
25/06/2026 11:17 pm
Legacy certificate validation failed because the assurance model no longer matched the threat model. The article shows that methods once tolerated for convenience had become structurally unsafe for publicly trusted issuance. A validation method that cannot reliably prove domain control is not a minor procedural weakness, it is a broken trust assertion. Practitioners should read this as a warning that certificate governance must be tied to the actual risk of misissuance, not to historical habit.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
A question worth separating out:
Q: Who is accountable when a certificate is misissued because of outdated validation?
A: Accountability sits with the organisation that approved or operated the validation process, even if the mistake is only discovered later. CAs, certificate managers, and governance teams all need clear ownership for issuance rules, evidence review, and replacement decisions. Without that ownership, revocation becomes a technical event with no clear operational answer.
👉 Read our full editorial: CAB Forum validation rule changes tighten certificate trust
