SC-34: Non-modifiable Executable Programs

Quick-reference card

What this control requires

SC-34 requires you to load and run your operating environment and designated applications exclusively from hardware-enforced, read-only media. That means the code your systems execute can’t be altered after it’s written to the storage medium, eliminating an entire category of runtime tampering.

In practice, this control targets the integrity of executable code at its most fundamental level. Instead of relying on software-based protections that attackers can circumvent once they gain elevated privileges, SC-34 mandates a physical guarantee. Hardware-enforced read-only media, such as CD-R, DVD-R, or one-time programmable read-only memory, prevent modification regardless of what access an attacker achieves on the running system.

The scope covers two distinct categories. First, the operating environment itself, which includes operating systems, executives, and virtual machine monitors (hypervisors), must load from non-modifiable storage. Second, any applications your organization designates as critical must do the same. This separation matters because it forces you to inventory which components require this level of protection and maintain documented justification for each designation. Organizations that treat NIST SP 800-53 as a compliance checkbox often overlook this inventory requirement, which is where most audit findings originate.

Why it matters

Most organizations never implement SC-34 because it sits outside every control baseline, making it functionally invisible during standard compliance scoping. That invisibility creates risk. When auditors or assessors evaluate system integrity controls, an unaddressed SC-34 signals a gap in your organization’s understanding of hardware-rooted trust, even if the control isn’t formally required for your authorization boundary.

Failure to maintain this control introduces audit risk for systems where software integrity is mission-critical. If your environment processes classified data, supports critical infrastructure, or operates in air-gapped networks, assessors expect to see evidence that you’ve evaluated SC-34’s applicability. A blanket “not applicable” without documented rationale invites follow-up findings and delays in authorization decisions.

The distinction between software-based integrity verification and hardware-enforced immutability is significant from a threat perspective. Software integrity tools like file integrity monitoring can detect unauthorized changes after they occur. SC-34 prevents those changes from being possible in the first place, which is a fundamentally stronger security posture for high-assurance environments.

Beyond your own systems, third-party vendors operating in sensitive environments should demonstrate equivalent protections. Vendor questionnaire responses that reference only software-based integrity controls, without addressing whether non-modifiable media is used for critical system components, leave a gap in your third-party risk assessment.

What attackers exploit

• Boot-level persistence: attackers who compromise the operating environment can install bootkits or rootkits that survive reboots and evade standard endpoint detection
• Hypervisor tampering: modifying virtual machine monitors gives attackers visibility into and control over every guest operating system running on the host
• Supply chain firmware implants: compromised firmware written to writable storage can persist undetected across system reimaging and hardware transfers
• Privilege escalation to storage modification: once an attacker gains administrative access, writable system media allows them to replace legitimate executables with trojanized versions
• Integrity monitoring evasion: sophisticated attackers can modify both the target files and the integrity baselines that monitor them, making software-only protections unreliable

How to implement

For your organization

The most common failure mode isn’t a lack of hardware-enforced media. It’s the failure to identify which system components warrant this level of protection. Organizations jump to procurement without completing the prerequisite inventory, then discover their designations don’t align with their actual risk profile.

Start by identifying every operating environment component and application that your system security plan designates as critical. Document the rationale for each designation, including the data sensitivity, threat model, and operational impact if that component were modified at runtime. This inventory becomes a foundational artifact for your assessment.

Evaluate your current boot architecture. Determine whether your systems boot from writable media, network storage, or read-only sources. For systems that currently boot from writable media, assess whether you can transition to CD-R, DVD-R, one-time programmable read-only memory, or other hardware-enforced non-modifiable storage. Thin client environments that boot from read-only network images can also satisfy this requirement when the image source itself is protected by hardware-enforced controls.

Implement a media creation and validation process. Every read-only image you create should go through a documented integrity verification workflow before deployment. Record cryptographic hashes at image creation time and verify them at deployment. Retain the hash records as evidence artifacts.

Address reprogrammable read-only memory carefully. NIST guidance permits reprogrammable ROM only when integrity is protected from initial writing through insertion into the system, with reliable hardware protections against reprogramming. Document the specific hardware mechanisms that prevent unauthorized reprogramming, and include this documentation in your system architecture records.

Common mistakes include treating UEFI Secure Boot alone as sufficient (it addresses boot integrity but doesn’t enforce non-modifiable storage), neglecting to update read-only images when legitimate patches are required, and failing to document the designated application list.

For your vendors

When vendors operate systems within your authorization boundary or process your sensitive data, you need evidence that they’ve addressed SC-34 for components where hardware-enforced immutability is warranted.

Start your assessment with targeted questionnaire questions:

• Do you load operating environments from hardware-enforced, read-only media for systems processing our data?
• Which system components have you designated for non-modifiable executable program controls, and what criteria drove those designations?
• What types of read-only media do you use (CD-R, DVD-R, one-time programmable ROM, other)?
• How do you handle patching and updates for components running from read-only media?
• If you use reprogrammable read-only memory, what hardware protections prevent unauthorized reprogramming?

Request specific evidence artifacts, not just policy documents. You’re looking for the vendor’s list of designated components, their system architecture documentation showing the boot chain, integrity verification records for read-only images, and configuration documentation for any reprogrammable ROM protections.

Red flags to watch for include vendors who claim full SC-34 compliance but can only produce software-based integrity monitoring evidence, vendors who lack a documented list of designated components, and vendors whose system architecture documentation shows all components booting from standard writable storage. A vendor responding with “not applicable” should provide documented rationale explaining why no system components in scope warrant non-modifiable executable protections.

Verify claims through independent assessment when possible. Request access to system design documentation and audit records rather than relying solely on self-attestation.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for this control.

You can explore related compliance requirements across frameworks on the NIST SP 800-171 overview page.

Related controls

• AC-03 — Access Enforcement: access enforcement controls complement SC-34 by restricting who can interact with the systems and media that SC-34 protects, ensuring that non-modifiable storage isn’t bypassed through unauthorized administrative access
• SI-07 — Software, Firmware, and Information Integrity: SI-07 provides software-based integrity verification that detects unauthorized modifications, while SC-34 prevents modifications from occurring by using hardware-enforced read-only media
• SI-14 — Non-persistence: SI-14 addresses the concept of non-persistent system components that revert to a known state, sharing SC-34’s goal of maintaining system integrity but through temporal controls rather than physical media restrictions

Frequently asked questions

What is NIST SP 800-53 SC-34?

SC-34 is a system and communications protection control that requires organizations to load and execute their operating environment and designated applications from hardware-enforced, read-only media. The control ensures software integrity from the point of image creation by making runtime modification physically impossible. It applies to both the operating environment (including operating systems, executives, and hypervisors) and any applications the organization designates as requiring this level of protection.

What happens if SC-34 is not implemented?

Organizations that don’t implement SC-34 where it’s warranted leave their system components vulnerable to runtime tampering, including boot-level persistence attacks and hypervisor modifications that evade standard detection tools. Assessors reviewing your system security plan will flag the absence of documented scoping decisions for SC-34, even if the control falls outside your required baseline. The resulting audit findings can delay authorization decisions and require compensating control documentation that often proves more burdensome than implementing the original requirement.

How do you audit SC-34?

Auditing SC-34 starts with verifying the organization’s list of operating system components and designated applications that must load from read-only media, then confirming that the hardware-enforced media types in use (CD-R, DVD-R, one-time programmable ROM) match what’s documented in the system architecture. Assessors examine media verification records, including cryptographic hash comparisons performed at image creation and deployment, to confirm the integrity chain is unbroken. They also review configuration documentation for any reprogrammable read-only memory to verify that hardware protections against unauthorized reprogramming are in place and functioning.

What types of hardware-enforced read-only media satisfy SC-34?

NIST guidance identifies CD-R, DVD-R, and one-time programmable read-only memory as acceptable hardware-enforced read-only media for SC-34. Reprogrammable read-only memory is also permitted if integrity is protected from the initial writing through system insertion, with reliable hardware protections against reprogramming. The key requirement is that the media enforces immutability at the hardware level, not through software access controls that could be bypassed with elevated privileges.