PKI Credential Issuance for Workforce and Government Identity

Issuing X.509 credentials is the lowest-glamour part of building a hardware-identity programme and the part most likely to get the system into trouble. This is the architecture, the actors, the lifecycle, and the decisions you can’t put off.

The cryptographic side of PKI is well-documented. The procedural side is where deployments break down. This post is the procedural side — what each role does, where keys live, what an issuance event actually looks like, and what changes when you move from workforce scale (thousands of credentials) to government scale (millions).

The roles

Four roles in every PKI deployment, even when they collapse into one team:

• Certificate Authority (CA). The thing that signs certificates. Holds the CA signing key. Operates in a tightly controlled physical/logical environment.
• Registration Authority (RA). The thing that decides who gets a certificate. Verifies identity, applies enrolment policy, formulates a certificate request, and forwards it to the CA.
• Validation Authority (VA). Provides revocation status — CRL distribution, OCSP responder.
• Subscriber. The user / device that receives and uses the certificate.

A workforce deployment usually runs CA + RA + VA as services owned by the IAM team, with the subscriber being an employee’s hardware credential. A government deployment usually separates them organisationally for accountability reasons.

Hierarchy design

The CA structure for a serious deployment is usually a two-tier offline-root hierarchy:

The reason for the offline root: if the issuing CA is compromised, you revoke and re-issue from the root without rebuilding trust roots in every relying party. If the root is compromised, every certificate downstream is suspect, and you would have to redistribute trust anchors to every relying party. That’s a programme-level disaster you isolate the root to prevent.

Key custody

The fundamental rule: CA signing keys never exist outside an HSM. Operationally this means:

1. The root CA key is generated inside an HSM at a key-ceremony. The ceremony is scripted, witnessed, recorded. M-of-N operators authenticate to the HSM; the key is generated; nobody sees the key bytes; the HSM keeps a sealed backup.
2. The issuing CA key is generated the same way, separately, in a different HSM (or a different HSM partition).
3. Both HSMs are FIPS 140-3 Level 3 or higher. For government workloads, Level 4 may be required.
4. Backup is in another HSM. Bring up a secondary HSM at ceremony time and import the wrapped key under M-of-N approval. The wrapped key is the only material that ever leaves the primary HSM, and it can only be unwrapped inside another HSM under the same approval policy.

The Registration Authority

The RA is where most deployments fail. Cryptography is easy; identity is hard.

The RA has to answer, for every certificate request:

• Who is asking? Identity verified via HR record, photo ID, biometric capture, all of the above.
• What are they asking for? A certificate over which public key? Bound to what hardware? Carrying what attributes?
• Are they entitled to it? Are they in the role that this certificate authorises?
• Is the key actually on certified hardware? This is the attestation question; we’ll address it below.

The RA enforces the answers. If it cannot, the CA signs untrusted certificates.

Attestation in the issuance flow

The CA should never sign a certificate over a key it doesn’t know is on certified hardware. The mechanism is attestation, and it has to be in the issuance flow, not bolted on afterwards.

How this works in practice:

1. The subscriber’s hardware (smart card, secure element, TPM) generates a keypair on-chip.
2. The hardware produces an attestation — a statement signed by a manufacturer key affirming the keypair was generated on a specific chip class.
3. The RA forwards the CSR + attestation to the CA.
4. The CA verifies the attestation against the manufacturer’s attestation root. If the chip class isn’t on the enterprise’s approved list, the certificate is refused.
5. Otherwise, the CA signs and returns the certificate.

Without attestation, the CA is signing assertions about a key the CA hasn’t verified. The certificate may end up over a software key in software storage; the relying party can’t tell. Attestation closes that gap.

Certificate profile

The certificate profile is the contract between the CA and every relying party. It specifies which extensions are present, which OIDs the policy uses, and what each one means.

Standard profile fields:

• Subject DN. The identity the certificate names. Typically CN=Display Name,O=Org,C=Country.
• Subject Alternative Name (SAN). The identities the certificate can authenticate as. Typically a UPN (user principal name) or email for workforce; structured identifiers for government.
• Key Usage. What the key can do — digital signature, key encipherment, etc.
• Extended Key Usage. Higher-level usage — client authentication, smart-card logon, code signing.
• Certificate Policies. OID identifying which policy this certificate was issued under (often references the CA’s Certificate Practice Statement).
• CRL Distribution Points / AIA. Where to find revocation status.
• Subject Information Access. Where to find the CA’s certificate.

Get this profile right at the start. Changing it later means re-issuing every certificate.

Enrolment protocols

• CMP (RFC 4210). Robust certificate-management protocol. Standard in many government deployments.
• EST (RFC 7030). Lighter-weight; common in IoT and modern enterprise.
• SCEP. Older, simpler, less secure by today’s standards; still common in network-device PKI.
• ACME. Web-PKI; not typically used for workforce smart-card issuance.
• Vendor proprietary. Many smart-card personalisation lines use vendor-specific protocols. Acceptable if attested-key support is preserved.

For a new deployment, EST is the strong default unless a specific scheme requires otherwise.

Lifecycle

The lifecycle conversation is in Designing Secure Credential Lifecycle Management; the PKI-specific bits:

• Validity. 1-3 years for end-entity certificates is standard. Government often 3-5 years.
• Rotation cadence. Plan to rotate before validity expiry, not at it. EST re-enrolment over the existing channel is the cleanest path.
• Revocation. CRL or OCSP. OCSP gives lower-latency revocation; CRL works offline.
• Algorithm migration. Plan how you move from current algorithms to future algorithms over the credential lifetime. The hardware has to support the migration; budget for it.

What changes at workforce scale

"Workforce" here meaning thousands to tens of thousands of credentials:

• Issuance is at an IT desk or via a small personalisation line.
• HSM throughput is comfortable.
• OCSP is the right revocation mechanism (low latency, modern).
• The RA is often integrated with the IdP’s admin API.
• Helpdesk is the day-to-day driver of operational load.

What changes at government scale

"Government" meaning hundreds of thousands to hundreds of millions of credentials:

• Issuance is at enrolment centres, biometric-capture, multi-step process. Often days between enrolment and credential collection.
• HSM cluster sizing matters; per-second signing throughput is a real constraint.
• CRL/OCSP infrastructure has to scale to the relying-party population. Often becomes its own subsystem.
• Audit, accountability, and separation of duties become regulatory requirements, not preferences.
• Trust anchors are widely distributed (national root, embedded in OS trust stores, deposited with foreign governments under bilateral agreements).
• Algorithm migration becomes a multi-year programme.

The architecture is recognisably the same; the scale of everything around it is different.

Practical guidance

1. Write the Certificate Practice Statement first. Not last. The CPS is the document everything else hangs off; without it, you cannot make consistent decisions.
2. Tabletop the key ceremony. Rehearse it. Time the operators. Surface every "what if" before the actual ceremony.
3. Attestation in the issuance flow, day one. Adding attestation later means re-issuing every credential.
4. Plan revocation propagation, not just revocation. A revocation that takes 24 hours to reach relying parties is a 24-hour vulnerability window.
5. Audit log everything. Issuance, ceremony, revocation, OCSP traffic, RA decisions. The log is the trust evidence.
6. Pick your hardware-credential class deliberately. See Smart Cards vs FIDO Tokens vs Passkeys for the matrix.

Related reading

• Designing Secure Credential Lifecycle Management
• Secure Element vs TPM vs HSM
• Smart Cards vs FIDO Tokens vs Passkeys
• Product: Digital Signature Token
• Solution: Government identity
• Solution: Workforce identity
• Case study: Passwordless workforce

Companion tools

• X.509 viewer
• PEM ↔ DER converter
• ASN.1 parser