SC-12(3): Asymmetric Keys

SC-12(3) requires you to produce, control, and distribute asymmetric cryptographic keys using your organization’s defined methods (the control’s organization-defined parameter). Operationalize it by standardizing how key pairs are generated, protected, issued to systems and people, rotated, revoked, and escrowed (if allowed), with clear ownership and audit-ready evidence. ¹

Key takeaways:

• Define and enforce one approved lifecycle for asymmetric keys: generation, storage, distribution, rotation, revocation, and destruction.
• Centralize control points (HSM/KMS/PKI) and restrict who can create or export private keys, with logging.
• Keep an evidence bundle that proves keys were created and distributed through approved channels, not ad hoc scripts or local keystores.

The sc-12(3): asymmetric keys requirement is narrowly worded but operationally broad: it expects your asymmetric key program to be intentional, repeatable, and provable. “Asymmetric keys” here covers key pairs used for TLS certificates, SSH access, code signing, document signing, S/MIME, VPN, identity federation, and any other public/private key use case in your environment. The control’s main risk is straightforward: if teams generate and share keys in inconsistent ways, you lose control over private keys, can’t reliably revoke compromised credentials, and struggle to demonstrate chain-of-custody during audits or incidents.

For most regulated environments aligned to NIST SP 800-53, auditors look for two things: (1) your organization-defined approach (the methods you chose) and (2) evidence that real keys were produced and distributed using those methods across key systems. This page gives you requirement-level implementation guidance you can hand to security engineering, IAM, and platform teams. It focuses on fast operationalization: define the standard, route all key creation and issuance through approved tooling, lock down key material handling, and retain a minimal but complete evidence set for exams and customer diligence. ²

Regulatory text

Requirement (SC-12(3)): “Produce, control, and distribute asymmetric cryptographic keys using {{ insert: param, sc-12.03_odp }}.” ¹

What that means for an operator

You must:

1. Choose and document the approved methods for asymmetric key production, control, and distribution (the organization-defined parameter).
2. Implement those methods in systems and workflows (PKI, KMS/HSM, certificate management, SSH key management, code-signing services).
3. Demonstrate control and traceability: who requested keys, who approved, where keys live, how private keys are protected, and how keys are revoked/rotated.

This is not a “write a policy” control. It is a “show me the lifecycle works in production” control. ¹

Plain-English interpretation

SC-12(3) expects your asymmetric keys to be managed like regulated credentials, not developer conveniences. You should be able to answer, with evidence:

• Where do key pairs come from (tooling and entropy source)?
• Who is allowed to generate or request them?
• How do public keys/certificates get distributed to relying systems?
• How do you prevent private keys from being copied, emailed, committed to repos, or left on laptops?
• How do you rotate and revoke keys when people leave, hosts are rebuilt, or an incident occurs?

Who it applies to (entity and operational context)

Entity types: federal information systems and contractor systems handling federal data aligned to NIST SP 800-53 expectations. ²

Operational scope (typical):

• Infrastructure/platform: TLS termination, service meshes, ingress controllers, load balancers, Kubernetes, cloud KMS/HSM.
• IAM and access: SSH keys, privileged access, bastions, SSO signing keys, federation certs.
• Software delivery: code-signing keys, artifact signing, CI/CD credentials.
• Business processes: document signing, S/MIME, customer communications.

If asymmetric keys exist in your environment, the lifecycle must be defined and enforced for the high-risk classes first (keys that authenticate humans, sign code, or terminate external-facing TLS).

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

Step 1: Define the organization-approved methods (the ODP)

Write down the “allowed ways” keys can be produced, controlled, and distributed. Your definition should be precise enough to test.

Minimum decisions to capture:

• Approved key generation locations: e.g., HSM-backed key generation for code-signing and CA keys; KMS for service keys; managed PKI issuance for certificates.
• Allowed key export rules: which key classes are non-exportable; when export is allowed; required approvals.
• Distribution mechanism: e.g., certificates issued via internal CA with automated enrollment; SSH via centralized SSH CA; application keys injected via secrets manager with short TTL where feasible.
• Algorithm and key size standards: reference your crypto standard and enforce via tooling (document the rule even if enforcement is phased).
• Ownership model: who owns PKI, who owns cloud KMS/HSM, who owns SSH key governance.

Deliverable: a short “Asymmetric Key Lifecycle Standard” that engineering can implement and auditors can test. ¹

Step 2: Inventory asymmetric key use cases and classify them

Build a pragmatic inventory:

• TLS certs (external-facing, internal, mutual TLS)
• SSH keys (human and machine)
• Code signing
• Identity signing keys (SAML/OIDC)
• VPN/device certs

Classify each by impact and handling requirements:

• Tier 1 (highest sensitivity): CA private keys, code-signing private keys, federation signing keys.
• Tier 2: production service identity keys, mTLS, privileged SSH.
• Tier 3: lower-impact internal keys with constrained blast radius.

This classification drives which keys must be HSM-backed, which require dual approval, and which can be automated. ²

Step 3: Centralize production and issuance through controlled systems

Auditors look for a single throat to choke:

• PKI / certificate management for TLS and identity certs.
• KMS/HSM for non-exportable private keys and signing operations.
• Central SSH model (commonly SSH certificates or managed key distribution) rather than unmanaged long-lived keys.

Control outcomes to implement:

• Only approved services can generate keys for sensitive tiers.
• Requests go through ticketed or workflow-based approval for high-risk keys.
• Key material is not generated on developer laptops for production use cases unless explicitly approved with compensating controls. ¹

Step 4: Put “control” into access control, logging, and separation of duties

Control is not just storage; it is governance.

• Restrict who can create, activate, rotate, revoke, recover, or export private keys.
• Require stronger controls for Tier 1: dual control for CA and code-signing operations, and tight break-glass rules.
• Enable immutable logging for key lifecycle events (issuance, rotation, revocation, failed access attempts).

A common audit hangup: logs exist, but they don’t tie to an owner or a review process. Assign a named team to review key-related events on a defined cadence and track exceptions to closure. ¹

Step 5: Define distribution paths that avoid direct private key handling

Distribution should minimize private key movement:

• Prefer certificate enrollment protocols and managed issuance for TLS.
• Prefer signing operations within HSM/KMS so the private key never leaves.
• For unavoidable private key distribution (legacy systems), define secure packaging, transport, and acceptance testing, with approvals and documented chain-of-custody.

If you must distribute private keys, treat it as a high-risk exception with compensating controls and time-bound remediation. ²

Step 6: Operationalize rotation, revocation, and decommissioning

Define triggers:

• Personnel departure or role change
• Host rebuild or compromise suspicion
• Certificate expiry windows
• Cryptographic standard updates

Make revocation real:

• Maintain CRL/OCSP where relevant for certificates.
• Disable or remove SSH principals/certs/keys promptly via centralized control.
• Track key “end of life” and ensure removal from systems and secrets stores.

If rotation is manual, it won’t happen consistently. Automate where feasible, and document where you cannot automate yet. ¹

Step 7: Build a control card and evidence bundle (so audits are fast)

Use a one-page control card:

• Objective (SC-12(3))
• Owner (role + team)
• In-scope systems
• Trigger events
• Step-by-step execution
• Exceptions and approvals
• Evidence produced and where stored

Daydream fits naturally here: many teams fail SC-12(3) in practice because they cannot show consistent operation across teams. Daydream-style control cards, evidence bundles, and recurring control health checks turn “we have a PKI” into “we can prove key production and distribution are controlled and repeatable.” ¹

Required evidence and artifacts to retain

Keep evidence that proves method + execution:

Governance

• Asymmetric Key Lifecycle Standard (ODP definition)
• Key classification/tiering criteria
• RACI / ownership for PKI, KMS/HSM, SSH, code signing

Technical configuration

• PKI/CA configuration summary (screenshots or exported configs)
• KMS/HSM key policies and role bindings
• Certificate profiles and issuance templates
• SSH CA configuration (if used)
• Approved crypto settings baseline (where documented)

Operational records

• Key/certificate issuance logs (sample set across systems)
• Access logs for key management actions
• Approval tickets for Tier 1 key events (creation/export/recovery)
• Rotation/revocation records and incident-driven key replacement evidence
• Exception register for non-standard key handling, with expiration and remediation owner

Ongoing assurance

• Control health check results and remediation tracker entries to closure ¹

Common exam/audit questions and hangups

Expect these questions:

1. “Show me your organization-defined methods for producing and distributing asymmetric keys.” ¹
2. “Which keys are non-exportable, and how do you enforce that?”
3. “Who can create or revoke production certificates, and how is that approved?”
4. “Prove a private key was not generated on a laptop for this production service.”
5. “How do you handle key compromise and prove revocation happened?”
6. “Do third parties ever receive your keys or signing capability? Show controls.”

Hangups that slow audits:

• Multiple PKIs with unclear ownership.
• Teams issuing certs through ad hoc scripts without consistent logs.
• SSH key sprawl with no central authority.
• Evidence scattered across cloud consoles, tickets, and chat threads.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails SC-12(3)	Fix
Policy says “keys must be protected,” but tooling allows local keygen everywhere	Control is not enforceable	Route issuance through PKI/KMS and block noncompliant patterns via CI checks and platform guardrails
No defined ODP methods	Requirement is literally incomplete	Publish the lifecycle standard and map each key class to an approved method 1
Private keys shared via email/chat or stored in repos	Loss of control and non-repudiation problems	Secrets manager + KMS/HSM-backed operations; add scanning and incident playbooks
Rotation depends on calendar reminders	Rotation becomes inconsistent	Automate issuance/renewal pipelines, then monitor for stragglers
Exception process has no expiry	“Temporary” becomes permanent	Time-bound exceptions with a single accountable owner and evidence of closure

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this control, so you should treat enforcement context as programmatic risk rather than case-driven precedent. The practical risk is consistent across environments aligned to NIST SP 800-53: unmanaged asymmetric keys create hard-to-detect persistence (SSH), enable impersonation (stolen private keys), and break trust chains (certificate misuse). ²

A practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Name an SC-12(3) control owner and publish the control card. ¹
• Draft the Asymmetric Key Lifecycle Standard (ODP methods): generation, control, distribution, rotation, revocation, exceptions.
• Inventory key use cases and identify Tier 1 keys and systems.
• Freeze risky behaviors with an interim directive: no new production private keys generated outside approved systems without written exception.

Days 31–60 (implement control points and prove operation)

• Route TLS issuance through one managed path (internal CA + enrollment or managed certificate service).
• Lock down KMS/HSM key policies for Tier 1 and Tier 2: restrict create/export/revoke permissions; enable logging.
• Stand up an exception register and start migrating the highest-risk outliers.
• Collect a first evidence bundle: configs, logs, and a sample of issuance and revocation records. ¹

Days 61–90 (scale, automate, and harden audits)

• Automate renewal/rotation where feasible; document remaining manual processes with named owners.
• Add periodic control health checks with tracked remediation items to validated closure. ¹
• Run an internal “mock audit”: pick a production system and trace its cert/key from request to issuance to revocation capability.
• Formalize third-party handling rules if any external parties interact with your PKI, code signing, or certificate issuance.

Frequently Asked Questions

What counts as “asymmetric keys” for SC-12(3)?

Any public/private key pair used for authentication, encryption key exchange, or signing, including TLS certificates, SSH keys, code-signing keys, and identity federation signing keys. Treat certificates as a primary distribution mechanism for public keys.

Do we need an HSM to meet sc-12(3): asymmetric keys requirement?

The control does not mandate an HSM, but you must use organization-defined methods and show they effectively control private keys. In practice, many teams choose HSM/KMS controls for the highest-sensitivity keys to reduce key export and copying risk. ¹

How do we handle legacy systems that require importing a private key file?

Put them on a documented exception path with compensating controls: restricted access, encrypted transfer, approval records, and a migration plan. Keep evidence that the exception was approved and reviewed.

What evidence is most persuasive to auditors?

A clear lifecycle standard (your ODP), system configurations that enforce it, and logs/tickets that show real issuance and revocation events happened through approved workflows. Auditors respond well to traceability from request to key creation to distribution. ¹

Does SC-12(3) apply to third parties that manage certificates for us?

Yes, if a third party is producing, controlling, or distributing keys or certificates on your behalf, you still need defined methods and oversight. Document the shared responsibility boundary and retain evidence of third-party controls in your due diligence package.

How should we scope this control for a multi-cloud environment?

Define common requirements (classification, approval, logging, rotation, revocation) and then map each cloud’s KMS/PKI services to those requirements. Your evidence should show consistent outcomes even if implementations differ by platform.

Footnotes

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

2. NIST SP 800-53 Rev. 5