SC-34: Non-modifiable Executable Programs

SC-34 requires you to ensure certain systems only load and execute executable programs that cannot be modified (or whose integrity is verifiably protected), so attackers cannot tamper with binaries between approval and runtime. Operationalize it by scoping the in-scope platforms, enforcing non-modifiable or integrity-verified execution paths, and retaining objective evidence that controls prevent and detect executable tampering. ¹

Key takeaways:

• Scope which platforms and execution paths are covered by SC-34’s “for [organization-defined parameter]” clause, then document that scope. ¹
• Enforce a technical mechanism that blocks modified executables from running (immutable media, signed code with verification, allowlisting with integrity checks). ²
• Keep assessor-ready artifacts: configuration baselines, signing/allowlisting policies, enforcement logs, and change records tying approvals to hashes/signatures. ²

The sc-34: non-modifiable executable programs requirement is a build-and-run integrity control: once an executable is approved for use, your environment must prevent that executable from being altered without detection and still being able to run. In practice, SC-34 gets implemented through a mix of (1) scoping decisions (which systems and program types are in scope), (2) technical enforcement (what stops modified code from executing), and (3) operational discipline (how software changes are approved, distributed, and evidenced).

The control text is intentionally parameterized: “For [organization-defined parameter], load and execute …” ¹. That means your first job as a CCO/GRC lead is to force clarity on what you mean by “for which systems” and “which executables,” and then ensure engineering has a mechanism that stands up in an assessment. Most findings happen because teams either implement a security feature but cannot prove it’s enforced, or they apply it inconsistently across server fleets, endpoints, or OT/embedded environments.

This page is requirement-level implementation guidance aimed at fast operationalization: what to deploy, who owns it, what evidence to retain, and what auditors commonly challenge.

SC-34 in plain English (what the requirement means)

SC-34 expects you to load and run executables in a way that makes them non-modifiable, or functionally non-modifiable, in the operational environment. “Non-modifiable” does not have to mean “physically impossible to change,” but it must mean you have strong controls so a changed binary cannot execute as if it were approved.

Translate that into an operator test:

• If an attacker (or admin mistake) changes an executable on disk, will the system prevent it from running, or reliably detect it before/during execution and block it?
• Can you prove the above with configuration evidence and runtime records?

The control is about executable integrity at the moment it matters: load and execute. It is not satisfied by a policy that says “don’t change binaries,” and it is not satisfied by ad hoc file monitoring without an enforcement point.

Regulatory text

Provided excerpt: “For {{ insert: param, sc-34_odp.01 }} , load and execute:” ¹

Operator meaning of the parameterized clause: SC-34 explicitly requires you to define the scope and conditions (“for [organization-defined parameter]”) and then implement a method that governs what executables can be loaded and run in that scope. Your System Security Plan (SSP) or control narrative must state:

1. what is in scope (systems, environments, program types), and
2. the enforcement method used to ensure executables are non-modifiable or integrity-verified at runtime. ²

Who it applies to (entity and operational context)

SC-34 is commonly assessed for:

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 is contractually flowed down or used as the control baseline. ²

Operationally, it applies anywhere you execute code that matters for mission/business outcomes:

• Server workloads (apps, batch jobs, admin tools)
• End-user endpoints (enterprise desktops/laptops)
• Privileged admin hosts and jump boxes
• Containers and orchestrated environments (where “executable” includes images and entrypoints)
• OT/embedded systems (where patching is constrained and integrity controls are critical)

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

1) Define “in-scope” for the SC-34 parameter

Create a short scoping statement that an assessor can test. Include:

• In-scope environments (prod, staging, corp IT, OT)
• In-scope asset classes (servers, endpoints, network appliances, container hosts)
• In-scope executable types (OS binaries, application binaries, scripts, installers, container images)

Decision tip: start with your highest-risk execution surfaces: internet-facing servers, privileged admin workstations, and systems processing sensitive federal data.

2) Choose an enforcement pattern that prevents modified executables from running

Pick one primary enforcement approach per platform, and document it:

Pattern A: Code signing + verification at load/execute

• Require signed binaries (and, where relevant, signed scripts)
• Configure the OS/runtime to verify signatures before execution
• Control certificate/private key management and signing approvals

Pattern B: Application allowlisting with integrity validation

• Allowlisting that ties authorization to hash/signature/publisher
• Enforce “deny by default” for unapproved executables in the scoped environment

Pattern C: Immutable/locked-down runtime media

• Read-only filesystems for system partitions
• Golden images where changes require rebuild/redeploy, not in-place modification

In practice, mature programs combine A or B with C for critical hosts.

3) Align the software change process to the enforcement point

SC-34 breaks if your change process and your enforcement mechanism are disconnected. You need a “through-line” from approval to runtime:

• Approved build artifact is generated in a controlled pipeline
• Artifact is signed or hashed
• Artifact is distributed through controlled channels
• Runtime checks enforce that only approved artifacts can execute

Your procedure should explicitly say what happens when an executable changes:

• Is it blocked from executing?
• Does it trigger an alert/ticket?
• Who approves the remediation path?

4) Implement monitoring that proves enforcement is active

Auditors often ask, “How do you know the control is working today?” Build evidence from:

• Allowlisting enforcement logs (blocked execution events)
• OS security logs for code integrity failures
• EDR detections tied to tampering attempts
• CI/CD attestations and signing logs for release artifacts

Monitoring is not the control by itself, but it is often the proof.

5) Assign ownership and set recurring evidence routines

SC-34 is cross-functional:

• Control owner: Security engineering or platform security (technical enforcement)
• Supporting owners: IT operations (endpoints/servers), DevOps (pipelines), GRC (documentation and evidence)

To reduce scramble during assessments, schedule recurring evidence pulls (monthly or per release) and store them in your GRC repository. Daydream is commonly used to map SC-34 to an owner, an implementation procedure, and a repeatable evidence checklist so you can produce the same artifact set every cycle without rebuilding the story. ¹

Required evidence and artifacts to retain

Keep artifacts that prove design, implementation, and operation:

Design / governance

• SC-34 control narrative (scope + enforcement approach)
• Secure software and change management procedure describing how executables are approved and distributed
• Exception process for legacy/OT systems (with compensating controls)

Technical configuration evidence

• Screenshots/exports of allowlisting or code integrity policies
• Configuration baselines for hardened hosts (read-only mounts, execution restrictions)
• CI/CD configuration showing signing steps and protected build variables/secrets

Operational evidence (most important in audits)

• Sample of blocked execution events and investigation tickets
• Release records that tie an approved build to a hash/signature and deployment
• Access control evidence for who can sign or publish executables

Retention approach: store “point-in-time” exports (not just “current state”) so you can prove operation during the audit period.

Common exam/audit questions and hangups

Assessors tend to pressure-test SC-34 with questions like:

• “Show me where the organization-defined scope is documented, and how you enforce it.” ²
• “If I modify this executable on a server, what prevents it from running?”
• “Do scripts count as executables in your environment?”
• “How do you handle emergency changes without bypassing signing/allowlisting?”
• “How do you ensure third-party supplied executables (agents, drivers, tools) meet the same requirements?”

Common hangup: teams demonstrate a tool, but cannot demonstrate enforcement (for example, allowlisting installed but in audit-only mode).

Frequent implementation mistakes (and how to avoid them)

1. Documenting scope vaguely (“all systems”)

   • Fix: list specific environments and asset groups, and note exclusions with explicit exceptions.

2. Relying on detection-only controls

   • Fix: require a preventive gate at execution (signature verification or allowlisting).

3. Allowlisting without change discipline

   • Fix: tie allowlist updates to change tickets and release approvals; keep a sample trail.

4. Ignoring “non-traditional executables”

   • Fix: explicitly decide how you treat scripts, macros, container images, and admin tools, then enforce accordingly.

5. No evidence of ongoing operation

   • Fix: establish a recurring evidence runbook and central repository. Daydream can structure SC-34 evidence collection as a repeatable checklist tied to the control owner and assessment calendar. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, SC-34 reduces the likelihood that malware, unauthorized admin behavior, or supply chain tampering results in successful execution inside your boundary. Risk increases sharply in environments with shared admin access, inconsistent patching, or ad hoc software distribution because attackers target exactly that gap: modify a trusted binary, then run it under trusted context.

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Name a SC-34 control owner and backups; confirm platform owners for endpoints, servers, and CI/CD. ²
• Write the scope statement for “for [organization-defined parameter]” and get sign-off from system owners. ¹
• Inventory execution surfaces: where executables come from and how they get deployed.
• Pick enforcement patterns per platform (signing, allowlisting, immutability) and document the decision.

Days 31–60 (Near-term)

• Implement enforcement on the highest-risk tier first (privileged admin hosts, internet-facing servers).
• Integrate signing/hashing into the release pipeline where feasible; restrict who can publish artifacts.
• Stand up evidence capture: baseline exports, policy configs, and a first set of runtime logs showing enforcement events.

Days 61–90 (Operationalize)

• Expand enforcement coverage to remaining in-scope assets; formalize exception handling for systems that cannot support it.
• Add monitoring and ticketing for blocked/failed integrity events; run at least one tabletop for “modified executable detected.”
• Run an internal assessment: select a sample host and demonstrate that a modified executable is blocked or detected with a recorded response.

Frequently Asked Questions

Does SC-34 require code signing everywhere?

SC-34 requires non-modifiable or integrity-protected execution for your defined scope, but the control text is parameterized so you choose where and how to enforce it. Code signing is a common method, but allowlisting with integrity checks or immutable runtime patterns can also meet the intent. ²

Are scripts and macros considered “executable programs” for SC-34?

Treat them as in scope if they can run with meaningful privileges or affect sensitive data workflows. The safest approach is to explicitly state in your scope whether scripts are covered and then enforce a corresponding integrity control (signed scripts, constrained language modes, or allowlisting). ²

How do we handle third-party software and agents?

Require third-party executables to arrive through controlled distribution channels and be covered by the same execution enforcement (publisher trust, signatures, or allowlisting entries). Keep an approval trail showing how the third party software was evaluated and added without weakening enforcement.

What evidence do auditors accept for “non-modifiable”?

Auditors typically accept configuration baselines proving enforcement is enabled plus operational logs showing blocked/failed integrity checks and the response workflow. Provide a sample chain from approved release to signed/hashed artifact to deployment record. ²

What if we have legacy or OT systems that can’t support allowlisting or signature enforcement?

Document a scoped exception, the business justification, and compensating controls (restricted admin access, controlled media updates, increased monitoring). Keep a plan to reduce or retire the exception, and evidence that the exception is reviewed.

How should a GRC team keep SC-34 “audit-ready” without chasing engineers every time?

Define a recurring evidence checklist tied to the control owner: baseline exports, policy status, sample logs, and change records. Daydream is often used to map SC-34 to owners and automate the recurring evidence request set so the artifacts stay current. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5