SC-34: Non-modifiable Executable Programs

SC-34 (Non-modifiable Executable Programs) requires you to ensure designated system components only load and run executable code that cannot be modified without authorization, typically by enforcing signed, verified, and integrity-protected executables. To operationalize it fast, define the in-scope components, enforce technical controls (signed boot/code execution, immutable images, allowlisting), and retain machine-verifiable evidence that the system blocks tampered code.

Key takeaways:

• Scope matters: you must name the specific system components where executables must be non-modifiable.
• Technical enforcement beats policy: auditors look for controls that prevent execution of altered code, not guidance docs.
• Evidence must be executable-focused: signing, verification logs, allowlist rules, golden images, and exception approvals.

SC-34 is a software integrity control. It is designed for the failure mode every operator fears: an attacker (or an over-privileged admin, or a compromised CI/CD pipeline) changes executable code and the system runs it. For a CCO, GRC lead, or security compliance owner, the practical task is to translate the control into a small set of enforceable rules: “What code is allowed to execute on which components, how do we prove it cannot be silently modified, and how do we handle emergency change?”

In practice, SC-34 is easiest to implement if you treat it as a combination of (1) scoping, (2) technical enforcement at load/execute time, and (3) a tight exception path. Scoping prevents never-ending debates about whether every laptop, container, or script is in scope. Technical enforcement provides the actual security outcome: only verified executables run. Exceptions keep engineering moving without blowing up auditability.

This page gives requirement-level guidance you can hand to infrastructure, endpoint, and platform owners and then audit against. It also tells you what evidence to retain so you can pass an assessment without scrambling for logs and screenshots later. Citations reference the NIST SP 800-53 Rev. 5 source materials provided. ¹

Regulatory text

SC-34 excerpt: “For [system components], load and execute:” ²

Operator interpretation of the excerpt: the control is intentionally parameterized. You must specify which system components are in scope, then implement a mechanism so those components only load and execute executables that are protected against unauthorized modification. Your assessment hinges on two points:

1. You explicitly define the scoped components (“for [system components]…”).
2. You demonstrate a technical enforcement that prevents or blocks modified executables from running (the “load and execute” decision point).
   ³

Plain-English interpretation (what SC-34 requires)

You need to prevent “silent code change” on key systems. If an executable file, library, kernel module, container image layer, or firmware component is modified outside your authorized change process, the system should refuse to run it or should only run a verified version.

A practical way to think about SC-34: execution must be conditional on integrity. Integrity can be enforced with signed code, measured boot, immutable “golden images,” application allowlisting, or a combination. The specific mechanism is your design choice, but it must be demonstrably effective at the moment the system loads or runs code. ⁴

Who it applies to (entity and operational context)

SC-34 commonly applies in environments aligned to NIST SP 800-53 Rev. 5, including:

• Federal information systems
• Contractor systems handling federal data
  ²

Operationally, you should expect SC-34 scrutiny anywhere execution integrity is critical:

• Production servers that process regulated data or mission workloads
• Identity systems (IdP, directory services), key management, and security tooling
• CI/CD runners and build servers (because they produce executables)
• Endpoints used for privileged administration
• Container platforms and artifact registries (if you deploy containers as executables)

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

1) Define scope: the “[system components]” list

Deliverable: a short, explicit list in your System Security Plan (SSP) or control statement.

• Identify components where unauthorized code execution would be highest impact (auth, network security, production compute, build pipeline).
• Include execution environments: OS, hypervisors, container runtime, serverless runtime, endpoint OS.
• Document boundaries: “Developer laptops excluded except privileged admin workstations,” or similar.

Tip: keep the first pass narrow and defensible; expand scope as maturity grows.

2) Choose your enforcement pattern (pick one primary, add compensating controls as needed)

Create a decision record that maps each component class to an enforcement method:

Common patterns

• Signed boot + kernel/driver enforcement for servers and endpoints (secure/measured boot, only trusted bootloaders/drivers).
• OS application allowlisting for endpoints and admin jump boxes (only approved binaries run).
• Immutable images for servers (golden images, immutable infrastructure, rebuild rather than patch-in-place).
• Container image signing + admission control for Kubernetes (only signed images from trusted registries can be deployed).
• Artifact integrity verification in CI/CD (verify checksums/signatures before release promotion).

Your goal is simple to test: “If I tamper with an executable, does execution get blocked or does the platform revert to a trusted version?”

3) Implement technical enforcement at load/execute time

This is the part auditors probe. Policy language does not satisfy SC-34 by itself.

Implementation checklist (adapt per platform):

• Configure trusted signing authorities (internal code signing CA or platform vendor trust store).
• Enforce verification (do not just “support” it): block execution or deployment when signatures are missing/invalid.
• Protect the allowlist policy itself from modification (admin role separation, config management, change control).
• Ensure updates follow an authorized path (signed updates, controlled deployment rings).
• For immutable servers/containers, enforce “build once, deploy many,” with integrity checks at promotion gates.

4) Build an exception path that does not break the control

You will need exceptions for emergency response, niche software, and legacy systems. Define:

• What qualifies (business justification + compensating control).
• Who can approve (system owner + security).
• Duration and review trigger (time-bound or event-bound).
• Required compensating telemetry (enhanced monitoring, file integrity monitoring, restricted access).

Exception discipline is a major audit differentiator: teams can move fast without turning SC-34 into a paper control.

5) Operationalize: control card, evidence bundle, control health checks

For sustained compliance, treat SC-34 like an operating control, not a project.

Minimum operating model:

• Control card/runbook: objective, owner, scope list, tooling, trigger events (new environment, new signing cert, platform upgrades), step-by-step execution, exception rules.
• Evidence bundle definition: what you capture each cycle and where it is stored.
• Control health checks: recurring validation that enforcement still blocks tampered code and that exceptions are current.

This aligns to the practical risk factor: teams often cannot show ownership, cadence, or evidence during diligence. ²

Required evidence and artifacts to retain (audit-ready)

Retain evidence that proves both design (what you intended) and operation (it actually works).

Design artifacts

• SC-34 control statement with scoped system components.
• Architecture diagram or inventory extract showing in-scope components.
• Configuration standards: code signing requirements, allowlisting standards, immutable build standard.
• Exception procedure and approval matrix.

Operational artifacts (high-value in audits)

• Screenshots/exports of enforcement configuration (allowlisting rules, admission control policies, secure boot status baselines).
• Logs showing verification decisions (blocked execution events, denied deployments due to invalid signatures).
• Sample of signed artifacts: signing certificate chain, signature verification output, artifact metadata.
• Change tickets for policy updates (allowlist changes, signing CA rotation, platform upgrades).
• Periodic test results: a documented negative test (“tampered binary blocked”) on representative systems.

Evidence storage: central GRC repository with immutable retention controls, plus links to source systems (SIEM, endpoint console, CI/CD). Daydream can hold the control card, map scope to system inventory, and standardize the evidence bundle so you do not rebuild it for every audit.

Common exam/audit questions and hangups

Expect these, and prepare short, evidence-backed answers:

1. “Which components are in scope for SC-34?”
   Auditors want a list, not “all production.” Provide the scoped component set and rationale.

2. “Show me that modified code cannot execute.”
   Have a live demo or a recorded test: tamper a file, show the block event, show the policy.

3. “How do you control the control?”
   If allowlists or signing policies can be edited by broad admins without tracking, SC-34 weakens. Show role separation and change control.

4. “How do you handle patches and updates?”
   Explain signed updates, promotion gates, and how emergency updates are approved and logged.

5. “What about scripts/macros/infrastructure-as-code?”
   Be explicit in scope: if scripts are treated as executables in your environment, include them; if not, document where they are governed (and why).

Frequent implementation mistakes (and how to avoid them)

• Mistake: Scope is vague or aspirational.
  Fix: name system components. Tie to inventory. Keep it current with a trigger when new components are introduced.

• Mistake: “We sign code” but don’t enforce blocking.
  Fix: require signature verification at execution or deployment time. Keep proof in logs.

• Mistake: Immutable infrastructure without integrity gates.
  Fix: immutability helps, but you still need trusted build and promotion. Add artifact signing and verification in the pipeline.

• Mistake: Exceptions become permanent.
  Fix: time-bound exceptions with periodic review triggers and compensating monitoring requirements.

• Mistake: Evidence is screenshots from last year.
  Fix: define the evidence bundle per operating cycle and collect it as part of routine control health checks.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat “enforcement” here as audit and customer diligence risk rather than a specific regulator penalty narrative. The operational risk is concrete:

• Unauthorized modification of executables enables persistence, credential theft, transaction manipulation, and covert exfiltration.
• Integrity breaks in CI/CD can propagate tampered artifacts broadly.
• Weak SC-34 evidence often shows up as a “control not operating” finding because the team cannot prove blocking behavior, only intent.
  ⁴

Practical 30/60/90-day execution plan

First 30 days (establish control design + scope)

• Assign a single accountable owner (security engineering or platform security) and a compliance owner (GRC).
• Publish the scoped “[system components]” list and document boundary decisions.
• Select the primary enforcement pattern per component class (signed execution, allowlisting, immutable images, container signing).
• Draft the SC-34 control card/runbook and the minimum evidence bundle.

Days 31–60 (implement enforcement + exceptions)

• Roll out enforcement on the highest-risk components first (identity, CI/CD, privileged admin workstations, production clusters).
• Implement an exception workflow with required compensating controls and approval steps.
• Stand up centralized logging for block/deny events and signature verification outcomes.
• Run a negative test on representative systems and store the results.

Days 61–90 (prove operation + make it repeatable)

• Expand coverage to remaining in-scope components.
• Run a control health check cycle and track remediation to closure.
• Validate evidence completeness: can you answer the top audit questions from artifacts alone?
• Operationalize change triggers (new platform, new signing cert, new cluster) so SC-34 stays current.

Frequently Asked Questions

Does SC-34 require code signing everywhere?

SC-34 requires non-modifiable executables on defined system components, not a single mandated technology. Code signing is a common method, but allowlisting, immutable images, and signed container admission controls can also satisfy the outcome if they reliably block modified code.

Are container images considered “executable programs” for SC-34?

Many teams treat container images as executables because they are the deployable unit that runs in production. If you do, enforce image signing and verify signatures at admission/deploy time, then retain deny logs as evidence.

How do we handle third-party software where we cannot sign the binaries ourselves?

Use allowlisting based on publisher signatures where available, restrict sources to trusted distribution channels, and control updates through a managed process. If neither signing nor strong allowlisting is feasible, document an exception with compensating monitoring.

What evidence is strongest for auditors?

Machine-generated evidence that enforcement is active: configuration exports, deny/block logs, and a documented negative test showing a tampered executable fails to run. Pair that with a scoped component list and an exception register.

Does file integrity monitoring (FIM) satisfy SC-34 by itself?

FIM detects change, but SC-34 focuses on what happens at load/execute time. If FIM is your primary measure, you typically still need a mechanism that blocks execution or forces restoration to a trusted version for in-scope components.

How should we document scope changes over time?

Add a trigger in the control card: new production platform, new cluster, new privileged workstation tier, or CI/CD redesign requires SC-34 scoping review. Keep a dated change log and link it to inventory updates and approvals.

Footnotes

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

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

3. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON

4. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 DOI