PKI governance: what teams miss about certificates and trust

TL;DR: Public key infrastructure is not just a technical specification but a mix of technology and policy, and different public PKIs exist for different trust models such as Web PKI, code signing, S/MIME, BIMI, and Matter, according to Red Sift. The governance lesson is that certificate trust is shaped by lifecycle rules, ecosystem control, and intended use, not by cryptography alone.

Editorial analysis by NHI Mgmt Group, based on content published by Red Sift: “How many public PKIs are there?”.

Key questions

Q: How should security teams govern certificates across multiple PKI ecosystems?

A: Security teams should segment certificate governance by trust domain, because web, code signing, email, and device PKIs do not follow the same policy or assurance model.

Q: Why is PKI more than a cryptography problem?

A: PKI is more than cryptography because trust depends on policy, operating context, and lifecycle control as much as on key pairs and signatures.

Q: What goes wrong when certificate trust is managed as one shared model?

A: The main failure is scope confusion.

Practitioner guidance

• Map each PKI use case to its trust domain Separate website, code signing, email, and device certificates into distinct governance domains so policy matches the trust model and lifecycle requirements.
• Assign clear lifecycle owners for certificates Define who issues, validates, renews, revokes, and audits certificates in each PKI context before automation expands the estate.
• Review trust assumptions by ecosystem Check whether browser-governed, vendor-governed, or specialised PKIs apply to the systems you operate, then adjust validation and monitoring accordingly.

Bottom line: PKI is best understood as governance plus cryptography, because policy determines how trust is created and enforced.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →