CA/B Forum certificate field changes sharpen PKI governance

At a glance

What this is: This is a compliance-focused update on CA/B Forum and Chrome root store changes affecting public TLS certificates and browser trust.

Why it matters: It matters because identity and infrastructure teams need to align certificate issuance, trust stores, and lifecycle processes with evolving browser and standards expectations.

👉 Read DigiCert’s CA/B Forum update on certificate fields and Chrome root policy

Context

The core issue is certificate governance, not a single browser announcement. When standards bodies narrow which certificate fields are valid and browsers define their own trust policies, PKI teams have to treat issuance, validation, and renewal as a lifecycle control problem, not just a certificate formatting exercise.

For identity and access teams, the impact reaches beyond web TLS. Certificate policy affects workload identity, service trust, and auditability, so changes in browser roots and certificate fields can expose weak ownership, stale issuance practices, and poor lifecycle discipline across the wider identity programme.

Key questions

Q: How should teams handle certificate profile changes without breaking trust?

A: Teams should inventory current certificate templates, identify where optional fields or legacy profiles are still in use, and test how reissued certificates behave in real trust stores. The goal is to separate valid legacy certificates from newly issued ones that must follow updated policy, then manage the transition centrally.

Q: Why do browser root store changes matter for PKI governance?

A: Browser root store changes matter because trust is no longer determined only by the operating system or issuing CA. A certificate can be acceptable in one environment and fail in another, so teams need browser-level validation, not just issuance approval and CA compliance.

Q: What breaks when certificate metadata is self-reported and unvalidated?

A: When certificate metadata is self-reported, it can create a false sense of identity assurance and lead teams to rely on fields that do not strengthen trust. That increases ambiguity in audits, validation, and troubleshooting, especially when multiple certificate profiles coexist during a transition.

Q: Who owns certificate lifecycle governance when standards change?

A: Ownership should sit with the team responsible for PKI governance, supported by application and platform owners who consume the certificates. Standards changes are operational events, so accountability must cover inventory, reissue timing, trust testing, and business communications before enforcement arrives.

Technical breakdown

OU field removal and certificate data minimisation

The OU field has historically carried organisational information inside certificates, but it is self-reported and not validated by the certificate authority. That makes it a weak identity signal in a trust system that depends on verifiable attributes. Removing optional, low-assurance fields reduces ambiguity and narrows the certificate to what can actually be trusted. In practice, this is a policy move toward cleaner certificate profiles and fewer misleading artefacts in validation workflows.

Practical implication: review certificate templates now and remove operational dependence on unverified certificate attributes.

Chrome root store and browser trust policy

A browser root store changes the trust model because the browser is no longer simply inheriting the operating system trust list. Instead, Chrome can define its own accepted authorities and root policy, which affects whether a site presents as trusted in that browser. For teams, browser trust becomes a direct governance dependency, especially where public TLS certificates must satisfy multiple trust ecosystems at once.

Practical implication: verify that public certificates remain trusted in browser-specific root programmes, not only in OS stores.

Certificate lifecycle management as policy enforcement

This update shows why lifecycle management matters as much as certificate issuance. When rules change, old certificates may remain valid while new and reissued certificates must conform to newer profiles, creating a mixed estate that is easy to mismanage. The real control challenge is inventory, renewal, and reissue discipline across all active certificates so policy changes do not turn into operational drift.

Practical implication: map which certificates will renew, reissue, or expire under the new policy and govern them centrally.

NHI Mgmt Group analysis

Certificate policy drift is a governance problem, not a browser tweak. When the acceptable shape of a certificate changes, organisations inherit a mixed estate of old and new profiles that do not behave the same way in audits, renewal flows, or trust validation. That is a lifecycle governance issue across PKI, not a one-time compliance notice. The practitioner conclusion is to treat certificate profile changes as a control change, not a formatting change.

Optional certificate fields create weak identity signals. The OU field was designed for a certificate environment where self-reported organisational detail could coexist with trust, but that assumption weakens once the field becomes misleading or inconsistently used. The implication is that certificate identity should lean on verified, policy-backed attributes rather than convenience fields that add ambiguity. Security teams should expect more pressure to rationalise certificate schemas and reduce trust in unvalidated metadata.

Browser trust is becoming a separate policy surface. Chrome’s move toward its own root store shows that trust decisions are increasingly fragmented across platforms, which means certificate governance can no longer assume OS-level trust is enough. This complicates validation, change management, and support because a certificate may be acceptable in one trust ecosystem and rejected in another. The practitioner conclusion is to validate trust at the browser layer, not only at the CA layer.

PKI maturity now includes reissue readiness. When industry rules evolve, the organisations that struggle are usually the ones that cannot quickly identify which certificates are affected, which templates need revision, and which business services depend on them. That is a lifecycle maturity gap, not just a technical one. The practitioner conclusion is to build certificate inventory and reissue response into standard governance, because standards changes are now part of normal operations.

From our research:

• 66% say their current tooling is not adequate to manage the scale of machine identities they now have, according to The Critical Gaps in Machine Identity Management report.
• 59% of companies face greater difficulties auditing machine identities, primarily due to lack of clear ownership and limited visibility, according to The Critical Gaps in Machine Identity Management report.
• For a broader governance lens, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for how inventory, rotation, and offboarding controls work across identity types.

What this signals

Certificate governance is moving toward stricter validation and narrower trust assumptions. Teams that still treat certificate fields as harmless metadata will face more friction as browsers and standards bodies continue to tighten accepted profiles. The programme-level response is to align issuance policy, trust testing, and renewal operations before those differences become outages or audit findings.

The practical signal is that PKI ownership is now part of identity lifecycle governance, not a separate infrastructure concern. Organisations that can map every active certificate, validate it against browser trust policies, and reissue at speed will absorb standards changes more cleanly than those relying on manual tracking.

For teams building this discipline, the lifecycle view in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the right companion resource because certificate governance now depends on inventory, ownership, and controlled reissue rather than static approval.

For practitioners

• Review certificate templates for unvalidated fields Identify where the OU field or similar optional attributes are still embedded in issuance templates, order forms, and downstream workflows. Remove operational dependence on fields that are self-reported and not CA-validated.
• Test browser trust against current root policies Check public TLS certificates against Chrome’s trust expectations, not only operating system trust stores. Validate that production sites present trusted chains in the browsers your users actually run.
• Map renewal exposure before policy enforcement lands Inventory new, renewed, and reissued certificates separately so you know which services will be touched when certificate profiles change. Use that map to prioritise remediation and communications.
• Centralise certificate lifecycle governance Tie issuance, reissue, renewal, and expiry tracking to a single governance process so policy updates do not create unmanaged drift across environments.

Key takeaways

• Certificate field changes are a governance issue because they change what can be trusted, validated, and audited.
• Chrome root store direction shows that trust is becoming browser-specific, so OS-level assumptions are no longer enough.
• Teams need inventory, template review, and reissue readiness to keep PKI policy changes from becoming service disruptions.

Key terms

• Certificate Profile: A certificate profile is the set of fields, constraints, and policy rules that define how a certificate is issued and validated. In practice, it determines which identity attributes are trusted, which are optional, and how much confidence relying parties can place in the certificate during authentication and policy checks.
• Root Store: A root store is the trusted list of certificate authorities used by a browser, operating system, or application to validate certificate chains. When trust is governed by multiple root stores, a certificate can be accepted in one environment and rejected in another, which creates operational and support complexity.
• Certificate Lifecycle Management: Certificate lifecycle management covers inventory, issuance, renewal, reissue, rotation, and expiry handling for certificates across an environment. It is the operational control that keeps trust current and prevents policy changes, expired certificates, or unmanaged reissues from disrupting services.
• Unvalidated Metadata: Unvalidated metadata is information included in a certificate or identity record that is self-reported or not independently checked by the issuing authority. It may be useful for administration, but it should not be treated as a strong trust signal because it can be inaccurate, inconsistent, or misleading.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: CA/B Forum Update October 2020. Read the original.