SC-34 Non-modifiable executable programs

What SC-34 non-modifiable executable programs requires in practice

SC-34 requires defined components to load and execute the operating environment and defined applications from hardware-enforced, read-only media, and no SP 800-53B baseline selects it. That single fact changes the conversation. The control is not a default for any impact level. It applies only when your organization selects it through tailoring or an overlay, usually because the system's assurance needs go beyond what the baselines ask for. If your team has been asked to show that operating systems and applications cannot be altered at rest, first confirm who made that requirement and whether it appears in your approved control selection. Then ask the assessor which of the two determination statements in SP 800-53A they will test against your scope.

The risk behind SC-34 is simple to state. If the operating system loader or an application binary sits on a writable disk, an attacker with administrative access, or a compromised update process, can replace it with a modified copy that looks normal to the running system. Ordinary file integrity checks help detect that change after the fact, but they depend on the same host that may already be compromised. Hardware-enforced read-only media moves the trust point down to the device, so the components that load your software cannot be rewritten by software running on the system. Assessors examine the list of operating system components and applications to be loaded this way, and the media used to load and execute each.

Meeting the control is hard for three practical reasons. First, the boot chain has to be designed so that firmware, bootloader, kernel and runtime all load from protected media, and any writable stage in the chain undermines the rest. Second, vendor patching assumes writable locations, so you need a documented process for building, testing and replacing images when security updates arrive, which ties SC-34 to the configuration and flaw remediation families. Third, many images were never built for read-only use, so logs, caches, package databases and temporary files need somewhere else to write. Confirm with your platform team and hardware vendor which media types they can enforce in hardware before you commit to a design.

Which systems and decisions bring SC-34 into scope

SC-34 applies only when the organization selects it or an overlay selects it, because no SP 800-53B baseline assigns it and FedRAMP Rev5 does not require it at Classes B, C or D. The cards below cover the decisions that determine whether the control becomes real work, and which systems an assessor will ask about first.

Selection through tailoring or overlays

SC-34 is never in a baseline by default. It enters scope only when the organization tailors a baseline to add it, or when an overlay that names it is adopted. Record the decision in the system security and privacy plan with a reason, so an assessor can see why the control is present or absent. Ask whether any contract, agency or internal policy has pulled it in, since that changes the scope without any change to the system itself.

Operating environments named as defined components

SC-34 requires the organization to define which components load and run the operating environment from read-only media. Each operating system image, hypervisor, container host and firmware image that the organization names becomes a parameter value the assessor will test. Keep an inventory of these images with their versions and the boot path each one uses, so the defined list matches what runs in production.

Applications named as defined components

The second parameter covers applications that must load from hardware-enforced, read-only media. Decide which applications are in that list, for example security agents, authentication components or payment software, and document the reason for each. Applications left off the list are outside the control, so the boundary decision needs to be explicit and reviewed when new software is added.

Hosts that boot from writable disks

Most servers and workstations boot from a writable system disk, which means SC-34 usually requires a change to how those hosts are built. Identify every host that boots from a writable disk and decide whether it will move to read-only boot media, stay out of scope with documented justification, or be replaced. Ask the platform team to confirm where the bootloader, kernel and root filesystem reside, since a writable boot partition is the usual gap.

Appliances and virtual machine templates

Appliances and golden virtual machine templates are often the easiest place to meet SC-34, because the vendor or build pipeline already produces a fixed image. Confirm with each vendor whether the appliance runs from read-only media or from writable flash, and whether its firmware can be modified in place. For templates, check whether instances are cloned from an immutable image or patched after deployment, because the second pattern weakens the claim.

Third-party software that must load read-only

Third-party software, including agents, drivers and vendor-supplied applications, may not support loading from read-only media at all. Before selecting SC-34, ask each vendor whether its product can run from a read-only filesystem, and what writes it needs at runtime, such as logs, temporary files or license state. Where a product cannot comply, record the exception and any compensating control, since the assessor will look for that record.

How to implement SC-34 step by step

This sequence turns SC-34 from a policy statement into a configured, testable state in which named operating system components and applications load only from hardware-enforced, read-only media. Each step ends with an artifact the assessor can examine.

Define the components named in the parameters
The organization owns this decision and records it in the system security plan. Its security, platform and application owners agree which operating system components and which applications must load and execute from protected media, filling the two organization-defined parameters that SC-34 provides for. Ask the assessor which granularity they expect, because the SP 800-53A examine objects refer to a list of operating system components and a separate list of applications. Done means both lists are approved, versioned and traceable to the system boundary. The output is the signed component list that the rest of the sequence depends on.
Choose the write protection mechanism per component
For each listed component, the platform engineering team decides whether it will sit on read-only media or on hardware-enforced write protection, and records the choice with its rationale. The decision depends on the hardware in the environment, the vendor's supported options and how often the component must change. SC-34 requires hardware enforcement, so a software-only lock does not satisfy the control on its own. Confirm each option with the hardware or platform vendor before committing. The output is a mechanism register that maps every listed component to its media and protection method.
Build or adapt the protected images
Engineers build the operating environment and application images with only the approved components, then write them to the chosen read-only media or protected store. Hashes of each image are recorded at build time so later loads can be compared to a known value. Build tooling runs in the organization's own infrastructure, and the image build procedure is documented with its inputs and signing steps. Done means every image has a recorded hash, a build record and a storage location that matches the mechanism register. The output is a set of signed, hashed images and their build records.
Configure the boot and load path
Administrators configure firmware and boot settings so the system loads its operating environment and applications from the protected media, and the write protection is enabled and checked in the firmware or hardware configuration. The configuration is captured as a baseline so changes to boot order or firmware settings are detectable. Confirm the exact configuration keys with the platform vendor, since they differ by hardware. Done means the boot path is documented, the protection is active and the baseline is stored under configuration management. The output is the boot and load configuration baseline with its verification record.
Test that components load from protected media
Testers boot the system in a controlled environment and confirm that every listed component and application loads from the protected media, not from a writable location. They attempt a controlled write to the protected media and record that the attempt fails, and they confirm that loaded binaries match the recorded hashes. This step maps directly to the two determination statements that SP 800-53A uses for SC-34. Results are recorded with the test date, the tester, the system version and any exceptions. The output is a test report that shows each component, its load source and the write attempt result.
Verify integrity after each boot
Teams add an ongoing check that confirms the loaded components still match their recorded hashes, so an altered component is detected rather than silently run. Open-source file integrity monitoring such as osquery can watch the relevant paths and record changes, and a backup tool with verify jobs such as Bareos can compare files against cataloged attributes. The team confirms which alerts route to the security operations function and how they are triaged. Done means the check runs on schedule and its alerts are tested with a deliberate, approved change. The output is the integrity monitoring configuration and a sample alert record.
Document the approved update procedure
Because protected media cannot be changed in place during normal operation, the organization must document how authorized updates are produced, tested, approved and written to new media. The procedure links to configuration change control, names the approvers and states how the previous image is retained for rollback. Confirm with the assessor how they expect the update path to be evidenced, because the procedure is the main control on how components change over time. Done means the procedure is approved, referenced in the system security plan and exercised at least once in a test environment. The output is the approved update procedure and the record of its exercise.

How an assessor tests SC-34 and what passes

This table maps the two SP 800-53A determination statements for SC-34 to the examine objects they name, the test approach, the evidence an assessor will ask for, and the findings that usually cause a gap. Read each row as one part of the assessor's walk-through, starting from the two organization-defined parameters that define the lists.

Assessment element	What the assessor checks	Evidence requested	Common findings
Organization-defined parameters	The organization has defined which operating system components and which applications must load and execute from hardware-enforced, read-only media	Written parameter values in the system security plan, with the reasoning for each selected component and application	Parameters left blank or described only as general hardening, with no named components
Determination statement 1: OS components	Operating system components listed as loaded from hardware-enforced, read-only media are in fact loaded that way at boot and runtime	Boot configuration, component inventory mapping each OS component to its read-only source, and a documented load path	Kernel or boot loader on a writable partition, or read-only media that is a writable image in practice
Determination statement 2: applications	Applications listed as loaded from hardware-enforced, read-only media actually execute from that media	Application inventory with install paths, launch configuration showing the read-only source, and a list of approved launch locations	Applications that start from writable paths such as user directories or temporary folders
Examine: media for OS environment	Media used to load and execute the operating environment is identified, hardware-enforced and read-only	Media inventory with make, type and write-protection mechanism, plus vendor documentation for the protection feature	Undocumented media, or media whose write protection is a software setting that can be reversed
Examine: media for applications	Media used to load and execute system applications is identified and matches the application list	Mapping of each application to its media, and change records for any media replacement	Writable boot partitions or shared volumes that hold application binaries alongside data
Interview	Administrators can explain how read-only media is created, updated and returned to service, and who approves changes	Documented update procedure for read-only images, named roles, and records of past image releases	Staff who do not know which components are read-only, or updates made directly to live media
Test	The assessor attempts or observes whether a listed component or application can be altered while the system runs	Test results showing write attempts are blocked, plus logs or integrity checks for any monitored paths	Successful writes to supposedly read-only paths, or no test performed before the assessment

Evidence that shows SC-34 is met and stays met

An assessor testing SC-34 checks the two determination statements against the examine objects in SP 800-53A, then looks for records that show the defined components really load from hardware-enforced, read-only media. The artifacts below map to those objects, and each one only holds value if it is refreshed between assessments, not rebuilt the week before one.

Component and media inventory

Start with a current list of every operating system component and application your organization has defined for read-only loading, with the media each one uses. This answers the examine objects for lists of components and applications directly. Tie each entry to a system identifier and a build version, and reconcile the list against the asset inventory every change cycle so that a new image or appliance cannot appear on the network without a matching entry. Ask the owner of each system to confirm the entry during scheduled reviews.

Media configuration and write-protection records

Record the hardware-enforced write protection on each medium, such as the media type, the controller or firmware setting that blocks writes, and the physical location of the device. Capture the configuration output from the device or hypervisor, not only the purchase order. Re-export these records after any hardware replacement, firmware update or move, because a changed controller setting can silently re-enable writes. Store the exports with a date and an owner so the assessor can see who verified them.

Boot and load configuration exports

Export the boot order, bootloader settings and the load path for each system so the assessor can see that the operating environment and applications start from the read-only source. Use the platform's own export tooling and store the output in version control. Compare the export against the approved baseline at each review, and treat any mismatch as a change that needs a record under your change control process. Confirm with your platform vendor which settings are visible to a read-only audit account.

Load test records

Keep dated test records that show each defined component boots and runs from its read-only medium. The examine and test methods in SP 800-53A call for evidence of actual loading, not only configuration. Repeat the test after each new image, after reboots in a maintenance window and after any hardware swap. Record the image hash, the medium identifier, the result and the tester. A single passing test from two years ago proves little about the system today.

Approved update procedure for read-only images

A read-only image is only controlled if the update path is also controlled. Document how a new image is built, tested, approved, written to media and deployed, and who may authorize each step. Link the procedure to your change management records and to the flaw remediation process. Review it at least once per assessment cycle and after any change to tooling, because a procedure that no longer matches practice is a finding in its own right.

Integrity and change monitoring records

Keep records from integrity monitoring that show whether the protected files, or the media images themselves, have changed. Tools such as osquery file integrity monitoring can record changes with a timestamp and path, and Bareos Verify jobs can compare files against cataloged attributes. Retain alerts and their dispositions, and check monthly that the monitored paths still match what the inventory says should be protected. Confirm the retention period with your own policy and your assessor before relying on these logs.

Open-source tools that produce SC-34 evidence

No open-source tool enforces read-only media on its own. SC-34 is satisfied by how the operating environment and applications are loaded, which is a hardware, firmware or image decision. The tools below do not replace that control. They help you show, repeatedly, that the files and programs on the running system still match what was loaded from read-only media. Confirm each tool's fit with your own platform, boot process and change process before you rely on its output as evidence.

Wazuh Security Configuration Assessment (GPL-2.0-only) scans monitored endpoints against YAML policies that check files, directories, registry keys and running processes, and it recommends remediation. Its policies are shipped mostly based on CIS benchmarks and can be extended with custom checks, so you can add rules for the specific executables and paths your assessor will ask about. Ask your team to confirm which checks the shipped policies cover on your operating systems, and to write custom checks for any read-only mount or image path that the defaults do not test.

Fleet (MIT) policies are yes or no questions asked of devices as osquery queries, and the policies page shows which devices in each fleet pass or fail each policy. This gives you a per-device record, useful for showing that every endpoint in scope still reports the expected read-only state. osquery (Apache-2.0 OR GPL-2.0-only) file integrity monitoring watches the paths listed under file_paths, records changes in the file_events table with the action, time and path, and calculates MD5, SHA1 and SHA256 hashes where possible. Bareos (AGPL-3.0-only) Verify jobs compare files against previously cataloged attributes, a Tripwire-like check for changes. Confirm that the Verify job covers the directories holding your loaded programs, and that catalog records are retained for the period your assessor reviews.

What meeting SC-34 costs in money and effort

This table lists the cost components of running SC-34 on a self-hosted platform, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No figures are given because none were supplied, so use the drivers to shape a written quote and ask each supplier to price every row separately.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Read-only media or write-protection hardware	Hardware vendor or the organization's procurement team	One-time, with replacement cycles	Number of defined components and whether hardware write protection exists on current devices or must be bought
Golden image engineering for OS and applications	Internal platform engineers or an implementation partner	One-time, then recurring with each image rebuild	Number of operating system and application images listed in the SC-34 parameters and how many distinct builds are needed
Boot and load configuration engineering	Internal engineers or implementation partner	One-time build, recurring tuning	Boot chain complexity, firmware variation across hardware and how many device models must load from read-only media
Testing that read-only loading works and fails safely	Internal QA, security testers or an implementation partner	Recurring with each image or firmware change	Vendor update frequency, number of test cases and whether tests run automatically in the change pipeline
Evidence upkeep and integrity monitoring configuration	Internal security operations, supported by open-source tools such as osquery, Wazuh or Fleet	Setup one-time, operation recurring	Number of monitored file paths, alert handling volume and how often the baseline must be re-captured after approved changes
External review and independent assessment	Independent assessor, not DeployOpen or any readiness provider	Recurring with each assessment cycle	Scope of SC-34 in the authorization boundary and the number of components the assessor chooses to sample
Auditor sampling and evidence requests	Organization staff time during the assessment	Recurring with each assessment cycle	Quality of exported evidence, such as image hashes, media inventories and integrity reports, and how quickly it can be produced
Open-source tooling licenses	No license fee for the listed tools, but configuration effort remains	Configuration one-time, operation recurring	Confirm each tool's license terms and support model before relying on them; the effort to configure and maintain policies is still paid

Who owns, implements and tests SC-34

The organization owns SC-34. It decides whether the control is selected at all, since SP 800-53B does not place it in any baseline, and it accepts the risk if it is not. Its security and platform staff define which operating system components and applications must load from hardware-enforced, read-only media, and they answer for that decision to the authorizing official or to their own governance board. Assessors will look for a named owner, a documented decision on the two organization-defined parameters, and proof that the design is operating.

Control selection: Record whether SC-34 is selected through tailoring or an overlay, and why.
Parameter decisions: Define the operating system components and applications that must boot and run from read-only media.
Operational ownership: Assign an accountable owner for the boot media, images and any exceptions.
Exception handling: Document which systems cannot meet the design and how the risk is accepted and tracked.
Internal review: Test the control before the assessor arrives, using the same procedures the assessor will follow.

Confirm that the organization's own team can explain every system in scope without the partner or the assessor in the room.

Where SC-34 usually falls short and how to close it

SC-34 is a narrow control, so its gaps are narrow too, but they recur. Most failures come from the distance between what the parameters name and what is actually read-only, or from evidence that describes one moment instead of the current state. The cards below cover five gaps an assessor is likely to find and a closing action for each.

Components missing from read-only media

The two organization-defined parameters name the operating system components and applications that must load from hardware-enforced, read-only media. Teams often fill these in from a generic image and forget agents, drivers, or helper binaries added later. Compare each named component against the media it actually loads from, and record any exceptions with a documented reason. Ask the assessor how they will sample components, since the examine objects list both components and applications separately.

Writable boot partitions kept for convenience

A boot or EFI partition left writable so kernel or bootloader updates are easier can defeat the control even when the root filesystem is read-only. The examine objects ask for the media used to load and execute the operating environment, so the boot path counts. Check the mount options and firmware write protection on every boot path, and document which step, if any, lifts protection for maintenance. Confirm the exact behavior with your hardware and firmware vendor.

Update procedures that bypass read-only media

A patch that is applied by writing directly to a running system, or by a script that remounts media read-write and forgets to restore it, makes the read-only state a formality. Define one approved update path that rebuilds or replaces the read-only image, and make any exception a logged, time-bounded change. Test the update path during change reviews so the assessor sees the same procedure the operations team follows. This connects to the system's configuration change control records.

One-time screenshots instead of a current inventory

A single screenshot of a mount table or a firmware setting proves the state on one day and nothing after. Assessors typically ask for evidence that shows the current state across the population of systems in scope. Build a recurring inventory that lists each system, its load media, and its mount and write-protection status, then review it on a schedule you can name. Ask whether your planned tooling can produce that inventory automatically.

No record of why SC-34 was selected

SC-34 is not assigned to any SP 800-53B baseline, so its presence in a system security plan needs a stated reason, whether it came from tailoring, an overlay, or an organizational risk decision. Without that record, the assessor cannot tell whether the control was considered or simply missed. Write a short decision record that names the selection source, the parameters chosen, the components covered, and the reviewer who approved the decision. Revisit it when the system boundary or its media changes.

Questions buyers ask about SC-34 cost, time and effort

Does a baseline require SC-34 non-modifiable executable programs?

No. SP 800-53B does not assign SC-34 to the low, moderate, high or privacy baseline, so it applies only when your organization selects it through tailoring or an overlay. Appendix C of SP 800-53 Rev. 5 lists it as implemented by the system and marks it as an assurance-related control. FedRAMP's Rev5 baselines also do not require it at Class B, C or D. Whether you need it depends on your system's risk assessment, your contract terms and any overlay your authorizing body applies. Confirm the selection with the authorizing official or contracting officer before you scope the work.

What drives the cost and effort of implementing SC-34?

The main drivers are the number of operating system and application components that must load from hardware-enforced, read-only media, the number of hosts or images involved, and how much of the environment is virtualized, containerized or cloud-hosted. Each component adds build, validation and rollback work. Effort also rises when existing patching and change processes must be redesigned, because read-only images change how updates reach production. Costs are mostly one-time for design and build, with recurring effort for image rebuilds, patch cycles and evidence collection. Ask for the cost split between these items in any written quote.

Can we implement SC-34 in-house without an outside partner?

Yes, if your team has the skills to build read-only boot and application media, manage image pipelines and document the design. An in-house team owns every decision and carries the ongoing work. Many organizations split the effort: internal staff keep ownership of the control, and an implementation partner prepares the systems, images and evidence. Whichever route you choose, the organization remains responsible for the control, and only an independent assessor can issue an assessment result. Confirm internal capacity against the assessment procedure's examine objects before you decide.

What does SC-34 require from our internal team?

Your team needs a named control owner, staff who understand your boot chain and image build process, and someone who can document where each operating system component and application is loaded from. The assessment procedure asks for lists of operating system components and applications loaded from hardware-enforced, read-only media, and for records of the media used to load and execute them. Engineers must also agree how updates are staged, tested and promoted, and security staff must review exceptions. Plan for participation from platform engineering, operations and the change board during design and handover.

How long does an SC-34 implementation take?

No duration figure is supplied for this control, so no timeline can be stated here. The schedule depends on the number of components in scope, the state of your build pipeline, whether hardware supports read-only boot, and how many change approvals are required. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any partner for a written scope that lists the systems covered, the component inventory, the deliverables, the dependencies on your teams and the dates for each milestone.

Can an implementation partner issue the SC-34 assessment?

No. An implementation partner can prepare systems, configuration and evidence for SC-34, but only an independent assessor or auditor can issue an assessment result. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Your organization owns the control and its determination. Ask your authorizing official or assessor which evidence they expect for the two determination statements, and confirm that the assessment team will test the read-only media claims directly.

What evidence will an assessor expect for SC-34?

Assessors work through the examine, interview and test methods in SP 800-53A. For SC-34, they will examine the lists of operating system components and applications loaded from read-only media, and the media used to load and execute each. They will also interview administrators about how images are built and updated, and may test whether a component can be modified at rest. Keep a current component inventory, build records showing the media used, change records for image updates and a clear exception process. Confirm the exact artifacts with your assessor before the assessment starts.

How DeployOpen scopes and prepares SC-34 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so SC-34 work starts with the organization's real boot, operating environment and application media. We prepare the systems and evidence an independent assessor will examine, while the organization keeps ownership of its controls and the assessor issues any findings.

How we scope

Confirm whether SC-34 is selected through tailoring or overlay, since no SP 800-53B baseline assigns it.
List the operating system components and applications that must load from hardware-enforced, read-only media.
Record the scope in writing before work starts, with deliverables and timelines agreed in advance in a fixed-scope engagement.

How we build

Identify the media used to load and execute the operating environment and each system application.
Configure read-only boot and application media in the client's cloud, data center or air-gapped network where the platform allows it.
Test that protected components cannot be altered at rest, and document any component that must remain writable and why.

How we hand over

Deliver a written description of each media list, its configuration and the tests performed against it.
Map the evidence to the two SP 800-53A determination statements so the assessor can trace each examine, interview and test step.
Name the open-source integrity tools used for monitoring, such as osquery file integrity monitoring, and explain their limits.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Review SC-34 evidence again when the operating system or application images change.
Confirm with your independent assessor which artifacts they expect before the assessment begins.