TL;DR: CA/B Forum discussions in October 2020 pointed to tighter certificate field restrictions, including likely removal of the OU field, while Google also advanced a Chrome root store model that changes how trust is established in browsers, according to DigiCert. The practical issue is not just certificate content, but how PKI governance, issuance, and browser trust decisions are enforced.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: Certificate field restrictions are tightening while browser trust policies are becoming more explicit.
Why it matters: For IAM and PKI teams, this matters because certificate governance now has to account for field-level policy change, issuance consistency, and browser-specific trust requirements rather than assuming legacy certificate semantics will persist.
Context
The governance gap here is simple: certificate policy is no longer static, and fields that were once accepted for decades can be narrowed or removed as industry rules evolve. For teams running PKI, that means certificate content, issuance workflows, and relying-party trust models all have to be governed together.
In practical terms, this article is about how browser trust and certificate issuance policy converge. The CA/B Forum is discussing limits on certificate fields, while Chrome is moving toward its own root store model, which changes how organisations should think about trust enforcement across public TLS deployments.
Key questions
Q: How should security teams respond when certificate fields are removed from public TLS profiles?
A: Treat field removal as a governance change, not a documentation update. Inventory every request template, renewal workflow, and validation rule that still depends on the field, then distinguish existing certificates from new issuance so legacy validity does not mask future noncompliance.
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 order forms keep optional legacy fields?
A: Operational drift breaks first. Teams start issuing certificates through templates that no longer reflect current standards, which creates inconsistent metadata, renewal friction, and audit exceptions when the CA or browser ecosystem stops accepting the old profile.
Q: Should organisations prioritise template cleanup or browser trust validation first?
A: Start with template cleanup if the issuance process still creates noncompliant certificates, then validate browser trust because both controls are necessary. If the certificate cannot be issued correctly, downstream trust checks only confirm a failure that was already built into the workflow.
Technical breakdown
Why certificate field governance is tightening
The OU field illustrates a common PKI problem: optional certificate data can become operationally confusing when it is self-reported and not independently validated. Once a field stops adding reliable trust value, standards bodies tend to narrow or remove it so issuers and relying parties have fewer ambiguous inputs. That shift is not only about certificate semantics, but also about reducing policy drift across CAs, order systems, and downstream consumers. For TLS, this means certificate profiles increasingly reflect what can be validated and enforced consistently rather than what has historically been allowed.
Practical implication: Prune certificate order forms and issuance templates to match current policy, not legacy field habits.
Chrome root store changes browser trust decisions
Chrome’s root store direction matters because browser trust is no longer simply inherited from the host operating system. A browser-managed trust model gives the browser vendor more direct control over which CAs are accepted and under what conditions. That changes the operational boundary for PKI teams: a certificate can be syntactically valid and still fail user-facing trust expectations if it does not align with the browser’s root programme. In practice, relying-party trust becomes a separate governance layer that cannot be assumed from generic OS trust stores.
Practical implication: Verify public TLS trust against browser root requirements, not only operating system trust stores.
Why certificate lifecycle controls must follow policy changes
When certificate fields or trust anchors change, the real risk is lifecycle inconsistency. Existing certificates may remain valid, while new, renewed, or reissued certificates are subject to different rules. That creates a governance split between legacy assets and current issuance policy, which can produce drift if inventory, renewal, and validation processes are not aligned. The issue is especially important for organisations with large public certificate estates, because policy change impacts renewal behaviour, support scripts, and the evidence available for audit and compliance.
Practical implication: Separate legacy-certificate handling from new-issuance governance so renewal workflows do not reintroduce deprecated fields.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Certificate governance has moved from static formatting to enforced policy. The OU field discussion shows that long-accepted certificate attributes can be reclassified when they no longer provide trustworthy value. That is a governance change, not a cosmetic one, because issuers, order workflows, and relying parties all have to converge on the same field model. Practitioners should treat certificate profiles as governed policy artefacts, not historical defaults.
Browser trust is now a distinct control plane. Chrome’s move toward its own root store means trust decisions can diverge from operating-system assumptions. This matters because an organisation can be compliant with its internal certificate process and still face browser trust failure if it does not monitor the browser’s root programme requirements. The practical lesson is that trust validation now spans both PKI operations and browser-specific policy.
Certificate profile drift: The real risk in this article is not simply field removal, but the gap between what an issuance system allows and what current standards permit. That gap creates avoidable renewal failures, support burden, and audit noise when old templates remain active after policy changes. Practitioners should tighten the link between certificate request templates, CA policy, and renewal governance.
Legacy validity does not equal future compliance. DigiCert notes that previously issued certificates with a valid OU field are not immediately impacted, but that should not be mistaken for a durable exception model. Governance teams need to distinguish grandfathered assets from future issuance rules, especially where public TLS, code signing, or S/MIME may eventually follow the same direction. The practitioner takeaway is to plan for transition windows as active governance work, not passive expiry cycles.
PKI policy is becoming more browser- and ecosystem-specific. The combination of CA/B Forum field restriction debates and Chrome root store development shows that trust is fragmenting into more explicit enforcement domains. That validates a broader NHI governance pattern: identity assertions must be checked in the actual consuming context, not only at issuance. Teams should expect more reliance on policy-specific validation rather than generic certificate acceptance.
What this signals
Certificate profile governance now needs the same discipline organisations already apply to identity lifecycle management. If request templates, renewal workflows, and trust-store assumptions are not aligned, the result is policy drift that only appears when a certificate is reissued or a browser changes its trust logic.
The practical signal for security teams is that certificate validity is becoming a context-specific property. Public TLS governance now depends on the intersection of CA policy, browser root stores, and local issuance controls, so inventory and renewal processes have to be managed as part of the control surface rather than as admin overhead.
For practitioners
- Update certificate request templates Remove deprecated or low-value fields such as OU from public TLS ordering workflows and align internal request forms with current CA/B Forum direction.
- Review browser trust assumptions Validate public-facing certificates against Chrome root store expectations in addition to operating-system trust stores so browser-specific trust failures are surfaced early.
- Separate legacy and new issuance policy Keep previously issued certificates under their original validity rules, but enforce the new field profile for renewals, reissues, and new public TLS certificates.
- Audit certificate inventory for field drift Check whether certificate templates, renewal scripts, and compliance checks still reference fields that standards bodies are likely to remove or narrow.
Key takeaways
- Certificate field restrictions are tightening because optional certificate data can create governance noise when it is not independently validated.
- Chrome’s root store direction shows that browser trust can diverge from operating-system trust, which changes how public TLS must be assessed.
- The control response is to align issuance templates, renewal workflows, and trust validation with current policy rather than legacy certificate habits.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST SP 800-57 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate field changes affect credential lifecycle and issuance governance for public TLS. |
| Recommendation — Apply IA-5 to govern certificate issuance, renewal, and revocation as controlled authenticator lifecycle processes. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Trust decisions depend on validated entitlements to use certificates in browser-facing environments. |
| Recommendation — Map certificate acceptance rules to PR.AA-05 and validate which roots and profiles are authorised. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged Access Rights | Public TLS certificate use is governed through tightly controlled privileged issuance rights. |
| Recommendation — Restrict certificate issuance rights and review template changes under A.8.2 governance. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Certificate governance is part of managing long-lived machine credentials across renewal cycles. |
| Recommendation — Treat certificates as long-lived credentials and remove deprecated fields from their lifecycle controls. | ||
| NIST SP 800-57 | Part 1 — Key Management Lifecycle | The article touches certificate governance as part of key and certificate lifecycle control. |
| Recommendation — Apply key lifecycle governance to align issuance, renewal, and trust decisions with current policy. | ||
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: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
- Public TLS: Public TLS is certificate-based trust issued through the public web PKI ecosystem. It lets browsers and other trusted clients authenticate a service and encrypt traffic without custom setup. The model is simple and widely accepted, but it follows external policy rules that the organisation does not control.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org