Your encryption infrastructure is evolving faster than your documentation. Certificate lifecycles are shrinking, quantum-resistant algorithms are moving from research to deployment, and trust models that worked for a decade no longer fit your architecture. You can't secure what you can't see.
This guide helps you build and maintain a cryptographic asset inventory that withstands organizational change, technology shifts, and the transition to post-quantum cryptography.
Scope
This guide focuses on cryptographic asset discovery and management for financial institutions subject to PCI DSS, FFIEC IT Examination Handbook, and Payment Services Directive 2 Strong Customer Authentication mandates. It covers symmetric keys, asymmetric key pairs, digital certificates, Hardware Security Modules (HSMs), and cryptographic dependencies in third-party components.
Out of scope: Application-layer tokenization schemes, biometric template storage, and blockchain consensus mechanisms.
Key Concepts and Definitions
Cryptographic asset: Any key, certificate, algorithm implementation, or HSM that performs encryption, decryption, signing, or verification operations on Cardholder Data or authentication credentials.
Crypto-agility: The ability to replace cryptographic algorithms, key lengths, or certificate authorities without application rewrites or architectural changes. A crypto-agile system separates algorithm selection from business logic.
Cryptographic dependency: A software library, hardware component, or external service that your systems rely on for cryptographic operations. Examples include OpenSSL versions, HSM firmware, and third-party payment SDKs.
Key Encryption Key (KEK): The Key Encryption Key (KEK) used to encrypt Data Encryption Keys (DEKs). Your KEK inventory determines your exposure during a key compromise or algorithm deprecation.
Requirements Breakdown
PCI DSS Requirements
Requirement 3.5: Document and maintain an inventory of cryptographic keys used to protect stored Cardholder Data. This includes DEKs, KEKs, and any keys used in Point-to-Point Encryption (P2PE) solutions.
Requirement 3.6: Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of Cardholder Data. Your documentation must specify key generation locations, distribution methods, storage controls, and rotation schedules.
Requirement 4.2: Never send unencrypted PANs by end-user messaging technologies. This requires tracking where encryption occurs in your message flow and which certificates authenticate those channels.
NIST Cryptographic Standards
FIPS 140-3: Cryptographic modules protecting sensitive data must meet FIPS 140-3 validation. Your inventory must record which HSMs and software modules have current validations and which are pending re-certification.
NIST SP 800-63B: Authentication systems must use approved cryptographic algorithms. If you're using older FIPS 186-4 signatures in your Multi-Factor Authentication flow, document the transition path to current standards.
Implementation Guidance
Discovery Phase
Start with certificate transparency logs and internal certificate authority records. These provide externally-facing TLS certificates and internal PKI hierarchies.
Query your HSMs directly. Most HSMs maintain key metadata: creation dates, usage counters, and algorithm identifiers. Export this metadata monthly. Compare exports to detect undocumented key creation.
Scan application configuration files for hardcoded key references, cipher suite specifications, and cryptographic library versions. Your Software Composition Analysis (SCA) tools already track dependency versions; extend them to flag cryptographic libraries specifically.
Map data flows that touch Primary Account Numbers. Where does encryption happen? Which component performs it? What key protects that data at rest? If you can't answer these questions for every PAN storage location, you lack adequate visibility.
Classification and Prioritization
Not all cryptographic assets carry equal risk. Prioritize based on:
- Data sensitivity: Keys protecting Cardholder Data or authentication credentials rank higher than keys encrypting log files.
- Algorithm age: SHA-1 certificates and 1024-bit RSA keys need replacement before AES-256 keys need rotation.
- Exposure: Internet-facing TLS certificates have different threat models than internal database encryption keys.
- Rotation capability: If replacing a key requires application downtime or vendor coordination, document that constraint now.
Building Crypto-Agility
Separate algorithm selection from implementation. Your application code shouldn't hardcode "AES-128-CBC"; it should reference a configuration parameter that your cryptographic policy controls.
Use key management services that support multiple algorithm families simultaneously. When NIST publishes post-quantum standards, you'll need to run hybrid modes where classical and quantum-resistant algorithms protect the same data during transition periods.
Test your rotation procedures under time pressure. Can you replace a compromised KEK in four hours? Eight? If your answer involves "contact the vendor," you lack crypto-agility.
Documentation Standards
Every cryptographic asset record must include:
- Asset identifier: Certificate serial number, key ID, or HSM slot reference
- Algorithm and key length: "RSA 2048" or "AES-256-GCM"
- Purpose: "Encrypts PAN in payment_data table" or "Signs API tokens for mobile app"
- Location: Hostname, HSM partition, or cloud KMS region
- Rotation schedule: "90 days" or "Certificate lifetime" or "Manual rotation only"
- Owner: Team responsible for rotation and incident response
- Dependencies: Applications, services, or external parties that rely on this asset
Common Pitfalls
Undocumented emergency keys: Developers create temporary keys during incident response. These keys never make it into your inventory and remain active for months.
Third-party cryptographic dependencies: Your payment gateway's SDK uses a specific OpenSSL version. When that version reaches end-of-life, can you update it without breaking your integration? If you don't track this dependency, you won't know until you're vulnerable.
Certificate lifecycle assumptions: You assume certificates renew automatically. They don't. Your inventory must include renewal dates and alert thresholds, not just current expiration dates.
HSM firmware versions: Your HSM firmware determines which algorithms you can use. If your firmware doesn't support post-quantum algorithms when standards finalize, you'll need hardware replacement, not just configuration changes.
Ignoring deprecated algorithms in non-production: Your test environment uses MD5 hashes because "it's not production data." Your developers learn cryptographic patterns from that environment. Document and remediate deprecated algorithms everywhere, or they'll appear in production during your next deployment.
Quick Reference Table
| Asset Type | Discovery Method | Rotation Trigger | PCI DSS Requirement |
|---|---|---|---|
| TLS certificates | CT logs, internal CA | 90 days before expiry | 4.2 |
| Database encryption keys | HSM query, app config | Annual or key compromise | 3.5, 3.6 |
| KEKs | HSM inventory, KMS API | Key compromise only | 3.6 |
| Code-signing certificates | Build system audit | Certificate expiry | Not directly required |
| API authentication keys | API gateway logs | 90-day rotation | 8.3 (if used for auth) |
| P2PE encryption keys | P2PE solution provider | Provider-managed schedule | 3.5 |
| HSM firmware | Vendor support portal | Security advisory or EOL | 3.6 (key management) |
Your cryptographic inventory isn't a compliance checkbox. It's your playbook for responding to the next algorithm deprecation, certificate authority compromise, or quantum computing milestone. Build it before you need it.
