SC-13(3): Individuals Without Formal Access Approvals

SC-13(3): Individuals Without Formal Access Approvals requires you to prevent people who lack formal authorization from gaining access to cryptographic functions, cryptographic keys, or the ability to influence encryption protections in your environment. Operationalize it by defining what “formal approval” means, locking down who can touch crypto material, monitoring for exceptions, and retaining evidence that approvals and technical restrictions work in practice. ¹

Key takeaways:

• Treat crypto administration (keys, HSMs, KMS, cert systems, TLS termination, encryption settings) as a privileged access domain with explicit approvals.
• Enforce “no approval, no access” technically (IAM, PAM, network controls, break-glass) and procedurally (requests, tickets, owner sign-off).
• Keep assessor-ready evidence: approval records, access lists, logs, and periodic reviews mapped to SC-13(3). ²

This requirement shows up as a practical access-control problem wrapped in cryptography language: who is allowed to handle cryptographic capabilities, and how do you stop everyone else? In most environments, “crypto access” is broader than an HSM console. It includes cloud KMS permissions, certificate authority administration, secrets management, the ability to change TLS configurations, and even the ability to modify encryption libraries or policies in CI/CD pipelines.

SC-13(3) narrows the focus to individuals who do not have formal access approvals. Your job as a Compliance Officer, CCO, or GRC lead is to make “formal approval” unambiguous, connect it to role-based entitlements, and prove that access pathways are controlled end-to-end (request → approval → provisioning → monitoring → review → removal). The fastest way to get this right is to map the requirement to a single control owner, a single operating procedure, and recurring evidence artifacts that stand up in an assessment. ²

Regulatory text

Excerpt (as provided): “NIST SP 800-53 control SC-13.3.” ²

What the operator must do: Implement controls so that individuals without formal access approvals cannot access or administer cryptographic protections (including cryptographic keys and cryptographic mechanisms) for the system. “Formal access approvals” must be defined, granted by an authorized approver, recorded, and enforced through technical access controls. ¹

Plain-English interpretation (what this really means)

SC-13(3) is about stopping “informal crypto admins.” If someone has not been explicitly approved to manage cryptography, they should not be able to:

• Read, export, generate, rotate, disable, or delete encryption keys.
• Change encryption settings (turn encryption off, weaken algorithms, change TLS ciphers).
• Administer certificate authorities, issue certs, or change trust stores.
• Access secrets stores in ways that expose key material.
• Modify production code/config that controls encryption behavior without the right gated approvals.

A common trap is treating this as only a Security Engineering/HSM control. Assessors often look for your definition of “formal approval,” your entitlement boundaries (what permissions are “crypto admin”), and whether exceptions are controlled and logged.

Who it applies to (entity and operational context)

Entities: Federal information systems and contractor systems handling federal data. ²

Operational context where this bites:

• Cloud environments using AWS KMS, Azure Key Vault, Google Cloud KMS.
• HSMs (on-prem or cloud) and any key ceremony processes.
• PKI/certificate tooling (enterprise CA, ACME automation, internal cert issuance).
• Secrets management (Vault, cloud secrets managers) where encryption keys or key-wrapping keys exist.
• CI/CD pipelines and configuration management where changes can impact encryption (Ingress controllers, service meshes, API gateways, databases).

Third-party angle: If a third party administers parts of your crypto stack (managed PKI, managed HSM, outsourced ops), SC-13(3) still applies. You need contract-aligned access boundaries, named roles, and evidence that only approved individuals at the third party can perform crypto administration.

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

1) Define “formal access approval” in one page

Write a short standard that answers:

• Who can approve crypto access (role/title, not a person).
• What prerequisites exist (training, background check if applicable, NDA, completed onboarding).
• Approval record format (ticket fields, e-signature, or IAM request workflow).
• Approval scope and expiry rules (time-bound vs ongoing; your choice, but document it). Tie it explicitly to sc-13(3): individuals without formal access approvals requirement so the intent is clear. ¹

2) Create an inventory of “crypto administration surfaces”

List systems and permissions that equate to crypto access. Examples to include:

• KMS key admin permissions (create/disable/schedule deletion/rotate).
• HSM admin roles and partition access.
• CA admin/RA roles and certificate issuance permissions.
• Ability to change TLS termination configs (load balancers, API gateways, ingress).
• Secrets manager admin roles that can view/export sensitive material. This inventory becomes the backbone of your entitlement reviews and audit evidence.

3) Map crypto surfaces to roles and least privilege

For each surface, define:

• Approved roles (e.g., “KMS Administrators,” “PKI Operators,” “Security Platform On-Call”).
• Disallowed roles (e.g., general IT admin, developer by default).
• Separation-of-duties rules where feasible (requestor ≠ approver; operator ≠ auditor). Then implement with IAM groups/roles, not direct user grants.

4) Enforce approvals through provisioning controls (technical gates)

Operational pattern that works:

• Access requests: Require tickets (or IAM workflow) with business justification and system scope.
• Approvals: Require the designated approver (security owner or system owner) and record it.
• Provisioning: Use SSO/IAM group membership, PAM check-out, or JIT access to grant.
• Blocking: Prevent “backdoor” access via shared accounts, static keys, or unmanaged local admin. Your aim is simple: no documented approval, no entitlement.

5) Put break-glass access on rails

You will need emergency access. Define:

• Who can invoke break-glass for crypto admin.
• Required incident/ticket linkage.
• Session recording or enhanced logging.
• Mandatory post-event review and removal. Assessors look for whether “emergency” becomes the default path.

6) Detect and review “unapproved crypto access” signals

Implement monitoring for:

• Direct user grants on KMS keys or HSM partitions outside the approved groups.
• New admin roles created or privilege escalation around key systems.
• Certificate issuance anomalies (unexpected issuer, unexpected SANs, new root/intermediate).
• Key deletion/disablement attempts. Tie alerts to an incident workflow and document the triage steps.

7) Run a recurring access review focused on crypto entitlements

Do periodic reviews (your cadence) of:

• Membership in crypto admin groups.
• Effective permissions on keys/cert systems.
• Third-party operator rosters (named individuals) where relevant. Record reviewer, date, findings, and remediation.

8) Map ownership, procedure, and evidence (assessment-ready packaging)

Make SC-13(3) easy to test:

• Name a control owner.
• Publish the procedure (request/approve/provision/review).
• Define the evidence you produce every cycle. This is the fastest way to reduce the “missing implementation evidence” risk called out for this requirement. ²

Where Daydream fits: Daydream is useful when you need a clean mapping from SC-13(3) to a control owner, an operating procedure, and a recurring evidence checklist so you can run the control the same way every time and answer assessor questions without scrambling. ²

Required evidence and artifacts to retain

Keep artifacts that prove both approval and enforcement:

Policy/standards

• Formal definition of “crypto administrative access” and “formal approval.”
• Access control/PAM standard covering crypto systems. ¹

Access governance records

• Sample access request tickets with approver identity, scope, and justification.
• Current list of approved crypto admins (by role and user).
• Break-glass invocation records with post-review closure notes.

Technical evidence

• IAM role/group configurations for KMS/HSM/CA/secrets tooling.
• Key policy snippets showing only approved roles can administer keys.
• Audit logs showing access events and admin actions (read/export/rotate/delete attempts).
• Evidence of periodic access reviews and completed removals.

Third-party evidence (if applicable)

• Contract clauses or SOC reports are helpful, but you still need your own access roster, approval workflow, and logs where you have them.
• Named list of third-party individuals authorized for crypto operations, with approval records.

Common exam/audit questions and hangups

Auditors and assessors tend to probe:

• “Show me your definition of formal access approval and who is allowed to grant it.” ¹
• “Which systems are in scope for crypto admin, and how did you identify them?”
• “Demonstrate that a developer without approval cannot administer KMS keys or modify TLS settings.”
• “How do you control and review emergency access?”
• “How do you detect unauthorized changes to encryption configuration?”

Hangups that stall assessments:

• You have approvals in email/Slack with no durable record.
• Permissions are granted individually instead of through roles.
• Cloud console admins implicitly have crypto admin powers and nobody noticed.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating ‘root/admin’ as acceptable for crypto management.
   Fix: Make crypto admin a distinct role with explicit membership and approvals; constrain super-admin paths.

2. Mistake: No inventory of crypto touchpoints.
   Fix: Build and maintain the “crypto administration surfaces” list; update it when onboarding new platforms.

3. Mistake: Break-glass is unlogged or never reviewed.
   Fix: Require ticket linkage and post-event review; remove access promptly.

4. Mistake: Third-party operators aren’t named or approved.
   Fix: Require named individuals, role-based access at the provider, and a review workflow aligned to your approvals.

5. Mistake: Evidence is implied, not retained.
   Fix: Predefine your evidence set and collect it on a schedule. This directly addresses the common risk of missing implementation evidence. ²

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat it as an assessment and incident-readiness issue rather than a citation-driven enforcement story. Practically, failure modes show up during:

• Authorization assessments (weak role definitions, missing approval records).
• Incident investigations (can’t prove who had crypto admin rights and why).
• Supply chain reviews (third parties with excessive access to keys or encryption controls).

The operational risk is straightforward: unapproved individuals with crypto admin access can disable encryption, exfiltrate keys, or issue trusted certificates. That turns a contained access issue into a broader confidentiality and integrity event.

Practical 30/60/90-day execution plan

Day 30: Stabilize and define

• Assign one control owner for SC-13(3) and publish the “formal approval” standard. ¹
• Build the first-cut inventory of crypto administration surfaces (KMS/HSM/PKI/TLS/secrets).
• Pull current entitlements and identify obvious over-permissioned accounts.
• Implement a mandatory ticket-based approval path for new crypto admin access.

Day 60: Enforce and instrument

• Convert direct grants into role/group-based access for crypto systems.
• Implement break-glass with logging and a documented review step.
• Turn on or validate audit logging for key admin actions and certificate issuance.
• Start a recurring access review workflow for crypto admin groups.

Day 90: Prove operation and close gaps

• Run an access review and document remediation actions to completion.
• Test “negative access” (pick non-approved users and prove they cannot administer keys/certs).
• Validate third-party crypto admin rosters and approvals where applicable.
• Package evidence: policy, role mappings, logs, review outputs, and exceptions register mapped to SC-13(3). ²

Frequently Asked Questions

What counts as “formal access approval” for SC-13(3)?

A documented authorization granted by an identified approver under a defined process, recorded in a durable system (ticketing or IAM workflow) and tied to specific crypto-admin permissions. The approval needs to be testable after the fact. ¹

Does this requirement apply only to HSM administrators?

No. Treat cloud KMS permissions, certificate administration, secrets management admin roles, and the ability to change encryption/TLS settings as in scope where those actions affect cryptographic protection. ¹

How do we handle developers who need to manage certs or keys for deployments?

Use automation identities with tightly scoped permissions and controlled pipelines, and keep humans out of direct crypto admin roles unless they have formal approval. Where humans must intervene, require JIT/PAM access with approvals and logging.

Is break-glass access allowed under SC-13(3)?

Yes, if you treat it as a formal, controlled exception: defined eligibility, time-bounded access, strong logging, and mandatory post-event review with documented closure.

What evidence is most persuasive to an assessor?

A clear approval record for each crypto admin, role-based enforcement in IAM/PAM, and logs that show key/cert admin actions are attributable and monitored. Package these as recurring artifacts mapped to the requirement. ²

How should we handle third-party managed KMS/PKI services?

Require a named list of third-party individuals with crypto admin access, align their access to your approval process, and retain periodic review evidence. If you cannot get direct logs, document compensating monitoring and contractual access constraints.

Footnotes

1. NIST SP 800-53 Rev. 5

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