SC-34 Non-modifiable Executable Programs asks that, for chosen system components, you load and execute the operating environment from hardware enforced read only media, and chosen applications from hardware enforced read only media.
NIST SP 800-53 binds US federal systems, and reaches contractors and cloud providers through contract terms such as FedRAMP. For everyone else it is a reference catalog you borrow from.
The guidance defines the operating environment as the code that hosts applications, including operating systems, executives and hypervisors. Examples of hardware enforced read only media are CD-R and DVD-R drives and one time programmable read only memory. Non modifiable storage preserves integrity of software from the point the image was created. Reprogrammable read only memory is acceptable if integrity can be protected. Three enhancements apply. SC-34.1 requires no writable storage, SC-34.2 integrity protection on read only media, and SC-34.3 hardware based protection.
What it means in practice
This is a high assurance control. Most companies will apply it to a handful of components, such as network appliances, kiosks, point of sale terminals or industrial devices. The cloud era has a loose cousin: immutable images where a server boots from a signed image and never changes in place. That is not the same as hardware enforced read only media, so describe it honestly as an alternative approach if your assessor accepts it.
Because this control is so specific, the most useful evidence is a clear scope statement. Say which components, if any, boot from read only media, and say why the rest do not. For most companies the honest answer is a very short list. An auditor would rather see a narrow control done properly than a broad one claimed loosely.
Some modern designs approach the goal. Secure boot with signed firmware, measured boot with a trusted platform module, read only root file systems, and signed container images all aim at the same property: the running code is the code you built. None of them is identical to hardware enforced read only media, and the enhancement about no writable storage in SC-34.1 is stricter than any of them. Describe the gap rather than hiding it.
Whatever you choose, the update path decides whether the control works. If you can push a new image through a signed, reviewed pipeline, you keep integrity and still patch. If anyone can write to the device, you have lost it.
Finally, tie the images to a bill of materials. A list of packages in each image is the starting point for checking that nothing known to be vulnerable ships inside a locked down device.
Evidence to collect
- The list of components in scope and the media each boots from.
- Hardware specification showing write protection.
- Image build records and hashes.
- Verification that the image running matches the build.
Common gaps
Devices described as read only that can be reflashed over the network. No way to prove the running image matches the original. Update procedures that bypass integrity checks.
How to implement it
Pick the small set of components where tampering is most costly. Boot them from signed, write protected images, record the hash at build time and check it at start. For servers, use immutable images and generate an SBOM for each image so you can list its contents. The free in-browser dependency scan at https://gold.safeguard.sh/scan can check a dependency manifest for known vulnerable packages before you bake it into an image.
Quick check
Is an immutable container image the same thing?
Not strictly. SC-34 speaks of hardware enforced read only media. Treat immutable images as a related practice and check with your assessor.
