CRYPTOGRAPHY AND KEY MANAGEMENT STANDARD

Approved Algorithms · TLS · Certificates · Keys · Secrets · API Tokens · CMK · FIPS

Table of Contents

1. Purpose and Scope
2. Approved and Prohibited Algorithms
3. Cryptographic Use Cases
4. TLS and Certificate Management
5. Key Management
6. Customer-Managed Keys (CMK) Decision Guide
7. Secrets, API Keys, and Tokens
8. Rotation Cadence
9. FIPS / FedRAMP / CUI Cryptography Checklist
10. Roles and Responsibilities
11. Document Control

1. Purpose and Scope

The Cybersecurity Policy requires encryption in transit and at rest. The IT, CUI, and Access standards each impose specific cryptographic requirements; the Risk Management Framework calls out FIPS-validated cryptography in CUI scope; the OT standard requires protection of BES Cyber System Information (BCSI). Until this standard, those requirements existed in fragments.

This standard establishes a unified cryptographic policy: which algorithms are approved, which are prohibited, how TLS and certificates are managed, how keys / secrets / API tokens are stored and rotated, when customer-managed keys are required, and the FIPS profile for regulated scopes.

It applies to every in-scope asset, every credential and secret used by CERG-managed systems, and every cryptographic use case, data at rest, data in transit, signing, integrity, authentication, and key wrapping.

The Crypto Standard Reads Like a Floor, Not a Ceiling

The algorithms and key sizes named below are minimums. Where a regulator, vendor capability, or specific workload supports a stronger configuration (post-quantum-ready KEM hybrid, larger key size, shorter rotation), CERG adopts it. The standard is the worst the program is willing to accept.

2. Approved and Prohibited Algorithms

2.1 Approved (NIST 800-131A current, FIPS 140-3 module where required)

2.2 Prohibited (Without Exception)

Exception Requests for Prohibited Algorithms

Exceptions to the prohibited list are not entertained as compensating-control bargains. The path to using a prohibited algorithm runs through replacing the system, not through a risk acceptance. The only acceptable exception is a time-bounded transitional one with a named sunset date.

2.3 Deprecation and Sunset Tracker

3. Cryptographic Use Cases

CERG controls cryptography at four use cases. Each names the required algorithm class and the key source.

3.1 Data at Rest

• Volume / disk encryption: AES-256 via OS or storage platform; keys in HSM or cloud KMS; rotation per Section 8.
• Database TDE / column-level encryption: AES-256; CMK for Restricted/CUI/SOX in-scope; rotation per Section 8.
• Object storage: server-side encryption with CMK for Restricted/CUI; client-side encryption optional where adversary model includes provider compromise.
• Backups: AES-256; key separate from production credentials (see CERG-STD-RES-001 Section 4).

3.2 Data in Transit

• External / public-facing services: TLS 1.2 minimum; TLS 1.3 preferred; HSTS enforced.
• Internal services: TLS 1.2 minimum; mTLS where the workload supports it and exposure warrants.
• Service-to-service in cloud: provider-native mTLS or service mesh-managed mTLS.
• Email: TLS for SMTP transport; S/MIME or PGP for content where CUI or sensitive content is in scope.

3.3 Authentication

• Human authentication credentials: see CERG-STD-AC-001 (phishing-resistant MFA, password storage requirements).
• Machine identities: certificates, signed JWTs, or workload identity (cloud-native), see Section 7.

3.4 Signing and Integrity

• Code signing: RSA-PSS 3072+ or ECDSA P-256+; keys in HSM; access logged.
• Container image signing: cosign / sigstore; signature verification enforced at admission per CERG-STD-CFG-001 Section 7.
• Log integrity: WORM storage and / or signing per CERG-STD-LM-001.
• Document signing: PKCS#7 / CAdES with RSA-PSS or ECDSA per use case.

4. TLS and Certificate Management

4.1 TLS Configuration

4.2 Certificate Inventory and Lifecycle

5. Key Management

5.1 Key Hierarchy

5.2 Key Operations

• Generation: in HSM or platform KMS; never on developer workstations.
• Distribution: via KMS APIs / agent enrollment; never email, chat, or ticket attachments.
• Storage: encrypted under a KEK; access logged.
• Use: least privilege; key admin separated from key user.
• Rotation: scheduled and event-driven (see Section 8).
• Backup / escrow: for keys that protect long-lived data, an escrow procedure exists; the escrow itself is HSM-resident and access-controlled.
• Destruction: keys destroyed via crypto-shred procedures with documented evidence.

5.3 Separation of Duties

| Action | Performed By | Approved By | CISO |—|—| | Generate root or issuing CA key | Two named operators | Engineering Pillar Leader | | Rotate KEK | Engineering - Platforms | Engineering Pillar Leader | | Generate CMK in production | Engineering - Platforms | Workload Owner + Engineering Pillar Leader | | Destroy / disable production key | Two named operators | Engineering Pillar Leader | | Export key material (rare; exceptional) | Two named operators | Engineering Pillar Leader + CISO |

6. Customer-Managed Keys (CMK) Decision Guide

The CMK decision is about who controls the master key, the customer (us) or the provider. CERG requires CMK for the cases below; otherwise provider-managed keys are acceptable.

6.1 CMK Required

• Data classified Restricted at rest.
• CUI in cloud / SaaS scopes (where the regulator permits a provider-managed alternative, CERG defaults to CMK anyway for crypto independence).
• BCSI stored in non-OT cloud / SaaS.
• SOX in-scope data where the auditor expects independent key control.
• High-Impact workloads where adversary model includes provider-side compromise.
• Any workload subject to a contractual obligation requiring customer control of keys.

6.2 CMK Not Required

• Internal-classification data in standard cloud/SaaS.
• Non-production environments.
• Workloads where the provider’s default key management has been assessed and accepted via the CERG-PRC-TPRM-001 Inheritance Evidence Package and risk-register entry.

6.3 CMK Operational Requirements

• Keys generated in cloud KMS HSM-backed (FIPS 140-2/3 Level 2+).
• Rotation per Section 8; rotation reuses prior key for read; new writes use new key.
• Key policy and access reviewed quarterly.
• Key material is never exported outside the HSM boundary except under the documented exception process.

What Inheritance Looks Like When CMK Is Not Required

“We use the provider’s default key management” is only acceptable when the Inheritance Evidence Package in CERG-GOV-CB-001 Section 5 is on file. Provider attestation, shared responsibility line item, customer-side configuration prerequisites, and re-papering trigger, all six elements, or CMK is required.

7. Secrets, API Keys, and Tokens

Plaintext secrets in source code, configuration files, environment variables on disk, or chat history are prohibited under this standard. The handling pattern below is the only acceptable approach.

7.1 Storage

7.2 Distribution and Use

• Pull, never push. Workloads retrieve secrets at runtime from the secrets manager; secrets are not baked into images or configs.
• Short-lived where possible. Tokens issued by IdP or STS preferred over long-lived static credentials.
• Scope-bounded. Each token is scoped to the minimum required resource and action.
• Logged. Issuance, retrieval, and revocation events flow to SIEM.

7.3 Detection and Hygiene

• Repositories scanned for committed secrets; finding revokes the secret and triggers credential reissue.
• CI/CD pipelines instrumented with secret-scanning gates.
• SBOMs reviewed for embedded secrets in third-party dependencies.

8. Rotation Cadence

8.1 Event-Driven Rotation Triggers

Rotation is also triggered by, not on a schedule alone:

• Suspected key / secret / credential compromise.
• Workforce changes affecting individuals with key access.
• HSM / KMS administrative anomaly.
• Vendor incident notification (per SCCT per CERG-PRC-TPRM-001).
• Algorithm deprecation or policy update.

9. FIPS / FedRAMP / CUI Cryptography Checklist

The checklist below is the minimum for any system in CUI scope, FedRAMP Moderate scope, or other regulatory scope that requires FIPS-validated cryptography. It is used at architecture review (CERG-PRC-AR-001) and at CMMC assessment readiness (CERG-PLN-CUI-001).

10. Roles and Responsibilities

11. Document Control

Source: standards/CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md · Download .md · View on GitHub