IA-13(1): Protection of Cryptographic Keys

If your systems issue or validate access tokens (for example, OAuth access tokens, refresh tokens, SAML assertions, or custom session tokens), the cryptographic keys behind those tokens are security-critical. A compromised token key can turn into immediate, broad authentication bypass because an attacker can mint “valid” tokens or decrypt token contents. IA-13(1) narrows the scope to a specific class of keys: the keys that protect access tokens.

This page translates IA-13(1) into requirement-level actions a Compliance Officer, CCO, or GRC lead can assign, track, and evidence quickly. The goal is not to debate crypto choices. The goal is to make sure the organization can demonstrate: (1) keys are generated securely, (2) keys are stored and accessed safely, (3) misuse is detectable, and (4) exposure can be contained through rotation and revocation. The common failure mode is not “bad algorithms.” It’s unmanaged sprawl: keys sitting in app config, long-lived keys with unclear owners, shared accounts accessing key material, and no clean evidence trail.

Regulatory text

Requirement: “Cryptographic keys that protect access tokens are generated, managed, and protected from disclosure and misuse.” ¹

What the operator must do: Identify every cryptographic key used to sign, encrypt, or otherwise protect access tokens, then implement a full key lifecycle (generate → store → use → rotate → revoke → retire) with controls that prevent disclosure and misuse, and produce evidence that those controls operate consistently. ²

Plain-English interpretation

IA-13(1) expects you to answer three questions with evidence:

1. Which keys protect access tokens? You can’t protect what you can’t name.
2. How are those keys generated and managed? Secure generation, controlled storage, and controlled use.
3. How do you prevent disclosure and misuse? Least privilege, separation of duties, logging/monitoring, rotation, and incident-ready revocation.

“Disclosure” includes keys exposed in source code, CI/CD logs, tickets, screenshots, chat, or backups that are broadly accessible. “Misuse” includes unauthorized signing, unauthorized decryption, or use of the wrong key for the wrong environment (prod key used in dev, or vice versa).

Who it applies to

Entities: Federal information systems and contractor systems that handle federal data, when adopting NIST SP 800-53 controls. ²

Operational context (systems and teams):

• Identity Providers (IdP), SSO platforms, and authorization services issuing JWTs/SAML assertions.
• API gateways validating tokens.
• Custom authentication/session services.
• Any service that encrypts token payloads or stores token “reference IDs” protected by crypto.
• DevOps/SRE teams operating key management infrastructure.
• Application teams that implement token issuance/validation.
• Security teams responsible for incident response and monitoring.

In scope key types (practical list):

• JWT signing keys (RSA/ECDSA private keys, or HMAC shared secrets).
• Keys used to encrypt tokens (JWE) or token-like artifacts.
• Keys used to protect refresh token storage (encryption at rest keys, wrapping keys) when compromise would enable token replay.
• Key-encryption-keys (KEKs) and wrapping keys used to protect the above.

What you actually need to do (step-by-step)

1) Build a “token key inventory” (the control anchor)

Create a register specifically for keys that protect access tokens, not a generic secret list. Minimum fields:

• Key name / identifier (kid), purpose (signing vs encryption), token type (access/refresh/SAML/custom)
• Owning system and business owner
• Technical owner (team/on-call)
• Environment (prod/non-prod)
• Key location (KMS/HSM/service)
• Allowed operations (sign, verify, encrypt, decrypt, wrap/unwrap)
• Rotation method and trigger (scheduled and emergency)
• Dependencies (which services validate the tokens)

Deliverable: a living inventory entry per key set, aligned to your token architecture.

2) Standardize key generation and storage

Define an approved pattern:

• Generate keys in a managed service (cloud KMS or HSM-backed solution) instead of generating locally on engineer laptops or inside app containers.
• Prevent raw key export wherever feasible for signing keys. If export is required for interoperability, document why, and add compensating controls (stronger access restrictions, short lifetime, strict logging).

Deliverables:

• Key generation procedure (runbook) for token keys.
• Platform standard that states where token keys may live (for example, “KMS/HSM only” for production).

3) Lock down key access paths (least privilege + separation)

Control objectives:

• Only the token issuer service can use signing keys to sign.
• Validators should not need the private signing key; they should use public keys or JWKS endpoints.
• Humans should not routinely access key material. If break-glass access exists, it must be time-bound and logged.

Implementation checklist:

• Map IAM roles to key operations (sign/decrypt is higher risk than verify/encrypt).
• Eliminate shared accounts and long-lived static credentials for key use.
• Require MFA and privileged access workflows for administrative actions on KMS/HSM keys.

4) Protect against disclosure in the SDLC and CI/CD

Common leakage points are build logs, debug statements, and configuration.

• Add automated checks to prevent committing key material (and to detect private keys/HMAC secrets).
• Verify that deployment pipelines retrieve keys at runtime via managed identity, not by injecting secrets into build artifacts.
• For JWKS publishing, ensure only public keys are exposed and endpoints are integrity-protected.

Evidence expectation: show that your engineering system reduces the chance that token keys appear in repositories or logs.

5) Implement rotation and revocation that actually works

Your program needs two modes:

• Planned rotation: routine replacement without breaking clients.
• Emergency rotation: rapid response when compromise is suspected.

Practical patterns:

• Use key IDs (“kid”) so token validators can accept multiple active keys during a transition.
• Maintain an overlap period where both new and prior keys validate, then retire the old key.
• Document revocation steps: how to disable a key, how to publish updated JWKS, how to invalidate outstanding tokens (if feasible), and who approves the action.

6) Monitoring and detection for misuse

You need telemetry that answers: “Who used the key, from where, and for what operation?”

• Enable and retain KMS/HSM audit logs for key operations (sign/decrypt/wrap/unwrap/admin changes).
• Alert on high-risk events: policy changes, key disablement, unusual call volume, calls from unexpected principals, or use outside normal regions/networks.

7) Tie it together with control ownership and recurring evidence

IA-13(1) fails in audits when teams say “we use KMS” but cannot show ownership, procedures, or repeatable evidence. Assign:

• Control owner (security/GRC)
• System owners (IdP/API platform)
• Evidence owners (platform team that can export logs and configuration snapshots)

If you use Daydream for control operations, this is where it helps: map IA-13(1) to a single owner, attach the runbook and inventory template, and schedule recurring evidence pulls (key inventory export, IAM review, rotation proof, logging proof) so assessment readiness doesn’t depend on heroics.

Required evidence and artifacts to retain

Maintain artifacts that prove design and operation:

Design evidence (static):

• Token key inventory/register (current)
• Key management standard for token keys (where generated/stored, export rules)
• Key lifecycle procedure (generate, rotate, revoke, retire)
• Architecture diagrams: token issuance/validation flow and trust boundaries

Operational evidence (recurring):

• KMS/HSM key configuration snapshots (policies, allowed principals, key states)
• Audit logs showing key operations and admin events (representative samples plus retention settings)
• Access reviews for principals permitted to administer or use keys
• Rotation records (tickets/change records + proof new keys created and old retired)
• Incident/break-glass records (if used): approvals, time bounds, and actions taken

Common exam/audit questions and hangups

Expect assessors to probe these areas:

1. “Show me all keys that protect access tokens.” If you hand over a generic secret list, you’ll get follow-ups.
2. “Where are keys generated, and can engineers export them?” Be ready to show export controls and who can do what.
3. “Who can sign tokens?” They’ll look for overbroad IAM grants and shared roles.
4. “How do you rotate without downtime?” They’ll want a documented method and evidence it happened.
5. “How do you detect misuse?” They’ll ask for logs, alerts, and examples of reviews.

Hangup to avoid: mixing “token signing keys” with “TLS cert keys” and assuming the same process covers both. Your process can be shared, but the inventory and evidence must clearly include token keys.

Frequent implementation mistakes (and how to avoid them)

• Mistake: HMAC secrets hardcoded in app config. Fix: migrate to asymmetric signing or store secrets in KMS with strict IAM and rotation.
• Mistake: Private keys stored in source control “temporarily.” Fix: block commits with automated scanning and require secure generation paths.
• Mistake: Single long-lived signing key with no overlap strategy. Fix: implement kid-based multi-key validation and planned rollover steps.
• Mistake: Validators have access to private signing keys. Fix: distribute only public verification material (public key/JWKS).
• Mistake: No evidence trail. Fix: define monthly/quarterly evidence pulls (inventory export, IAM policy diff, rotation log) and store them in your GRC system of record.

Enforcement context and risk implications

No public enforcement cases were provided in the available source catalog for this requirement, so this page does not cite enforcement outcomes.

Risk-wise, token key compromise is high impact: it can enable forged authentication artifacts or unauthorized decryption of token contents, depending on design. IA-13(1) is “medium” severity as a control label in your catalog, but the operational impact of a failure can be severe in a token-based architecture. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and make scope explicit)

• Name the control owner and system owners for token services.
• Build the token key inventory and validate it with engineering.
• Identify any keys stored outside approved platforms (code, config files, shared secret stores).
• Turn on audit logging for key management events where available and confirm retention is configured.

Days 31–60 (close the biggest exposure paths)

• Migrate high-risk keys into managed KMS/HSM (starting with production token signing keys).
• Restrict IAM policies to least privilege for sign/decrypt and separate admin from use.
• Publish and test a rotation runbook (planned and emergency) in a lower environment, then in production during a controlled window.

Days 61–90 (prove repeatability and assessment readiness)

• Run at least one planned rotation end-to-end with evidence capture.
• Implement alerting for key policy changes and anomalous key usage.
• Establish a recurring evidence cadence: inventory review, access review, and key operation log sampling, stored in your GRC repository (Daydream or your existing system).

Frequently Asked Questions

Do “cryptographic keys that protect access tokens” include OAuth client secrets?

Usually no; client secrets authenticate the client, but IA-13(1) is focused on keys that protect the token itself (signing/encryption). Track client secrets under your general secrets management controls, and track token signing/encryption keys under IA-13(1). ¹

Are public keys in a JWKS endpoint considered “keys that must be protected from disclosure”?

Public keys are intended to be disclosed, but you still must protect their integrity and availability because clients rely on them to validate tokens. Protect the private key from disclosure; protect the JWKS publication path from tampering. ²

We use a third-party IdP. Are we still responsible for IA-13(1)?

Yes, you remain accountable for control outcomes. For a third party IdP, collect evidence of their key management controls (reports, architecture notes, or contractual commitments) and document how you validate key rotation and JWKS integrity in your environment. ²

What’s the minimum evidence an assessor will accept?

Plan to show a token key inventory, a key lifecycle procedure, IAM/access control proof for key use/admin, and logs or reports showing key operations and at least one rotation or key change event captured as evidence. ¹

Can we meet IA-13(1) if keys are exportable from KMS?

Potentially, but exportability raises disclosure risk and increases the evidence burden. If export is required, document the business/technical reason, restrict who can export, log exports, and reduce the blast radius with tighter rotation and strict handling procedures. ²

How do we scope this in a microservices environment with many issuers?

Start from token issuance points: any service that signs or encrypts a token is in scope. Standardize issuance through a shared auth service or gateway where possible, then inventory and control the smaller set of keys rather than many ad hoc implementations. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5