NIST Cybersecurity Framework and PKI: A Practical Implementation Guide

The NIST Cybersecurity Framework (CSF) is the most widely adopted cybersecurity framework globally. Version 2.0 (released February 2024) organizes cybersecurity activities into six functions: Govern, Identify, Protect, Detect, Respond, and Recover.

PKI and certificate management touch every single function. Certificates are how you identify assets, protect communications, detect anomalies, respond to compromises, and recover from incidents. Yet most CSF implementations treat PKI as an afterthought — a checkbox under “encryption” rather than a foundational capability that enables the entire framework.

Here’s how to properly map PKI to the CSF and build a certificate management program that satisfies the framework’s requirements.

---

NIST CSF 2.0 Functions and PKI Mapping

GOVERN (GV) — Establish Cybersecurity Strategy

The Govern function (new in CSF 2.0) establishes organizational context, strategy, and oversight.

PKI relevance:

CSF Category	PKI Implementation
GV.OC: Organizational Context	Document PKI’s role in business operations (what depends on certificates?)
GV.RM: Risk Management Strategy	Include cryptographic risk in risk register (algorithm deprecation, key compromise, CA failure)
GV.RR: Roles and Responsibilities	Assign certificate ownership (who manages which certificates?)
GV.PO: Policy	Cryptography policy, key management policy, certificate management policy
GV.OV: Oversight	Management review of PKI health (expiry dashboards, compliance reports)

Practical steps:

1. Document: "These business processes depend on certificates: [list]"
2. Assign: Certificate ownership to specific teams/individuals
3. Policy: Written cryptography policy (algorithms, key sizes, rotation schedules)
4. Review: Quarterly PKI health review with management
5. Budget: Allocate resources for certificate management tooling

---

IDENTIFY (ID) — Understand Your Cryptographic Assets

The Identify function is about knowing what you have and what’s at risk.

PKI relevance:

CSF Category	PKI Implementation
ID.AM: Asset Management	Certificate inventory (all certs, keys, CAs across infrastructure)
ID.RA: Risk Assessment	Assess: expired cert risk, weak algorithm risk, CA compromise risk
ID.IM: Improvement	Track PKI maturity over time, identify gaps

Practical steps:

Certificate Discovery:
├── Network scan all TLS endpoints (ports 443, 8443, 636, etc.)
├── Query cloud APIs (ACM, Key Vault, GCP Cert Manager)
├── Enumerate Kubernetes Secrets (all clusters)
├── Monitor CT logs (certificates issued for your domains)
├── Scan SSH authorized_keys (all servers)
└── Inventory API tokens and service accounts

For each certificate, document:
├── Subject/SANs (what it identifies)
├── Issuer (which CA)
├── Expiry date
├── Key algorithm and size
├── Deployment location(s)
├── Owner (responsible team/person)
├── Renewal method (automated/manual)
└── Compliance scope (PCI, HIPAA, etc.)

---

PROTECT (PR) — Implement Safeguards

The Protect function implements controls to ensure service delivery.

PKI relevance:

CSF Category	PKI Implementation
PR.AA: Identity Management and Access Control	Certificate-based authentication (mTLS, smart cards, device certs)
PR.DS: Data Security	Encryption in transit (TLS) and at rest (key management)
PR.PS: Platform Security	Secure CA infrastructure (HSMs, access controls, hardening)
PR.IR: Technology Infrastructure Resilience	CA high availability, certificate automation, backup procedures

Practical steps:

Encryption in Transit:
├── TLS 1.2+ on all services (internal and external)
├── Strong cipher suites only (AEAD, forward secrecy)
├── Certificate automation (ACME, cert-manager)
├── mTLS for service-to-service (zero trust)
└── HSTS on all public endpoints

Encryption at Rest:
├── AES-256 for all sensitive data
├── Key management via KMS/HSM
├── Automated key rotation
└── Separation of keys from data

CA Infrastructure Protection:
├── Root CA offline (HSM, air-gapped)
├── Issuing CA in HA configuration
├── HSM for CA signing keys (FIPS 140-2 Level 3)
├── Access control (M-of-N for admin operations)
└── Audit logging of all CA operations

Certificate Automation:
├── ACME for public certificates
├── cert-manager for Kubernetes
├── CLM platform for enterprise-wide management
├── Automated renewal (no manual processes)
└── Verification after deployment

---

DETECT (DE) — Identify Cybersecurity Events

The Detect function finds anomalies and potential incidents.

PKI relevance:

CSF Category	PKI Implementation
DE.CM: Continuous Monitoring	Certificate expiry monitoring, CT log monitoring, anomaly detection
DE.AE: Adverse Event Analysis	Correlate certificate events with security incidents

Practical steps:

Certificate Monitoring:
├── Expiry alerts (60, 30, 14, 7 days)
├── Renewal failure alerts (cert-manager not ready, ACME failures)
├── CT log monitoring (unauthorized certificates for your domains)
├── Weak algorithm detection (SHA-1, RSA-1024 still in use)
├── Chain completeness verification
└── Certificate configuration drift detection

Anomaly Detection:
├── Unusual certificate issuance volume
├── Certificates from unexpected CAs
├── Signing operations outside business hours
├── Certificate used from unexpected IP/location
├── Key access patterns deviating from baseline
└── Failed mTLS handshakes (potential compromise indicator)

SIEM Integration:
├── Feed certificate events to SIEM
├── Correlate with network/auth events
├── Alert on combined indicators
└── Retain for incident investigation

---

RESPOND (RS) — Take Action on Incidents

The Respond function manages detected cybersecurity incidents.

PKI relevance:

CSF Category	PKI Implementation
RS.MA: Incident Management	Certificate compromise response procedures
RS.AN: Incident Analysis	Determine scope of key/certificate compromise
RS.MI: Incident Mitigation	Emergency certificate revocation and re-issuance

Practical steps:

Certificate Compromise Response Plan:
1. DETECT: Alert triggers (unusual signing, CT log anomaly, key exposure)
2. ASSESS: What certificate/key is compromised? What does it protect?
3. CONTAIN: 
   ├── Revoke the certificate (CA revocation + CRL/OCSP update)
   ├── Block the compromised certificate at network level (if possible)
   └── Isolate affected systems
4. ERADICATE:
   ├── Generate new key pair
   ├── Request new certificate
   ├── Deploy to all affected systems
   └── Verify new certificate is serving
5. RECOVER:
   ├── Confirm all systems operational with new certificate
   ├── Verify revocation is propagated (CRL published, OCSP updated)
   └── Monitor for continued use of compromised certificate
6. LESSONS LEARNED:
   ├── How was the key compromised?
   ├── How can we prevent recurrence?
   └── Update procedures and controls

Timeline targets:
├── Detection to containment: < 1 hour
├── New certificate issued: < 4 hours
├── Full recovery: < 24 hours
└── Post-incident review: within 1 week

---

RECOVER (RC) — Restore Normal Operations

The Recover function restores capabilities after an incident.

PKI relevance:

CSF Category	PKI Implementation
RC.RP: Recovery Planning	CA disaster recovery, certificate backup procedures
RC.CO: Recovery Communication	Notify relying parties of certificate changes

Practical steps:

CA Disaster Recovery:
├── Root CA key backed up to secondary HSM (tested annually)
├── Issuing CA can be rebuilt from backup within 4 hours
├── Certificate inventory enables rapid re-issuance
├── Automation (ACME/cert-manager) handles bulk re-issuance
└── DR tested annually (simulate CA failure, measure recovery time)

Certificate Recovery:
├── If CA is lost: rebuild from backup, re-sign Issuing CA
├── If Issuing CA is compromised: revoke, sign new Issuing CA from Root
├── If bulk certificates expire: automation re-issues from working CA
└── If trust store is corrupted: redistribute CA certificates via MDM/GPO

---

CSF Maturity Levels for PKI

Level	Description	PKI Characteristics
Tier 1: Partial	Ad-hoc, reactive	No inventory. Certificates expire without warning. Manual everything.
Tier 2: Risk Informed	Some awareness, inconsistent	Partial inventory. Some monitoring. Mix of automated and manual.
Tier 3: Repeatable	Formal policies, consistent	Complete inventory. Automated renewal. Monitoring with alerts. Documented procedures.
Tier 4: Adaptive	Continuous improvement, proactive	Full automation. Short-lived certs. Crypto-agility. PQC planning. Predictive analytics.

Most organizations are Tier 1-2 for PKI. The CSF goal is Tier 3 minimum, Tier 4 for critical infrastructure.

---

Quick Assessment: Where Are You?

Score yourself (1-5) on each:

□ Certificate inventory completeness (do you know ALL your certs?)
□ Expiry monitoring coverage (are ALL certs monitored?)
□ Automation level (what % of renewals are automated?)
□ Key management maturity (HSM? KMS? Or plaintext files?)
□ Incident response readiness (can you revoke and re-issue in < 4 hours?)
□ Policy documentation (written crypto policy? Key management procedures?)
□ Ownership clarity (every cert has a named owner?)
□ Compliance evidence (can you produce audit evidence on demand?)
□ Supply chain visibility (do you know your vendors' cert posture?)
□ Crypto-agility (can you swap algorithms without re-architecting?)

Score:
40-50: Tier 4 (Adaptive) — excellent
30-39: Tier 3 (Repeatable) — good, continue improving
20-29: Tier 2 (Risk Informed) — gaps exist, prioritize
10-19: Tier 1 (Partial) — significant risk, act immediately

---

FAQ

Q: Is NIST CSF mandatory? A: For US federal agencies: yes (Executive Order 13800). For private sector: voluntary but widely expected by customers, partners, and insurers. Many contracts and RFPs require CSF alignment. Cyber insurance underwriters increasingly use CSF as their assessment framework.

Q: How does CSF 2.0 differ from 1.1 for PKI? A: CSF 2.0 adds the Govern function (organizational oversight, policy, roles) and strengthens supply chain security. For PKI, this means: documented crypto policies are now explicitly expected (Govern), and supply chain certificate management is highlighted (Identify/Protect).

Q: Can I use CSF alongside other frameworks (ISO 27001, SOC 2)? A: Yes — CSF is designed to complement other frameworks. NIST provides mapping documents between CSF and ISO 27001, COBIT, CIS Controls, etc. Implementing CSF for PKI satisfies overlapping requirements in multiple frameworks simultaneously.

Q: What’s the minimum viable PKI program for CSF Tier 3? A: Complete certificate inventory + automated renewal for all certificates + expiry monitoring with alerts + documented crypto policy + incident response procedure for certificate compromise + annual review. This covers the core requirements across all six functions.