SR-9 Tamper resistance: requirements and evidence

What SR-9 tamper resistance and detection requires

If you own SR-9 for a system, component or service, the core ask is to run a tamper protection program across its life cycle. SR-9 is a base control in the Supply Chain Risk Management family of NIST SP 800-53 Rev. 5, and it is the control that asks whether someone could alter hardware, firmware or software between manufacture and deployment, or while the system is running, and whether you would notice. SP 800-53B assigns SR-9 to the high baseline only, and that baseline also selects the multiple-stages enhancement, SR-9(1). Release 5.2.0 defines no organization-defined parameters for SR-9, so the program scope is yours to document. The control was moved into this family from SA-18, which NIST has withdrawn, so older programs that cite SA-18 should be re-mapped to SR-9 in their control inventory.

The risk is modification that happens outside your direct view: a router shipped with altered firmware, a server whose boot image was swapped in a staging warehouse, or a maintenance laptop that picked up malicious code during a field repair. The difficulty is that the evidence is spread across teams. Procurement holds acquisition documents, logistics or a receiving team handles physical custody, the deployment team records installation, and operations or a field service provider performs maintenance. No single group sees the whole chain, so a program that exists only on paper will not show how a component was protected at each stage. Confirm early which team owns each stage and who signs off on handoffs.

Which systems, components and suppliers SR-9 reaches

SR-9 is a high baseline control, so the first scoping question is which systems fall there. Once that is settled, the program reaches into hardware and firmware, the places devices travel through, and the teams and third parties who buy, maintain and retire them. Each decision below changes how much inspection, documentation and coordination the program requires.

Systems at the high baseline

SR-9 and its enhancement SR-9(1) appear only in the high baseline in SP 800-53B, so a system categorized at moderate or low impact does not need the control by default. Confirm the impact categorization with the authorizing official before scoping, because a single high-impact function can move a whole system into scope. If the system is assessed under FedRAMP, the Rev5 baselines require SR-9 and SR-9(1) at Class D, so check which class applies before you size the work.

Hardware and firmware components

The control reaches the system, system component or system service, so each device, appliance, server and network element that holds or processes system data needs an entry in the tamper protection scope. Firmware and boot components matter as much as the chassis, because a modified firmware image is a common way to hide a compromise. Start from the component inventory and mark which items are physically accessible to people outside your control.

Physical location and transit

Devices stored in unlocked rooms, shipped through third-party couriers, or deployed to remote sites carry more tampering risk than devices in a controlled data center. Define which locations and transit routes trigger inspection, and record who handles each device between the supplier and your facility. Expect the program to grow with the number of remote sites and the number of hand-offs, so price the inspection effort against that footprint.

Acquisition and receiving teams

Procurement, receiving and logistics staff are often the first people to see a device that has been opened, repackaged or delivered out of sequence. They need written procedures for checking seals, packaging and serial numbers, and a path for escalating anything unexpected. Acquisition contracts should also require suppliers to follow the same tamper protection steps, which connects this card to the SR-5 and SR-8 controls.

Maintenance and repair providers

Field technicians, repair depots and managed service providers can open a device without the organization ever seeing the activity. Each third party that touches a high-baseline component should be bound by the program through contract terms, access rules and a record of what was changed. Ask for the repair logs and firmware versions before and after service, and check them against the baseline recorded in your configuration management data.

Inventory systems that hold the evidence

The inspection and tamper records only prove the program works if the inventory behind them is current. Asset management tools can hold the serial numbers, locations and custody history for each component, and the monitoring stack can record file and configuration changes after deployment. Confirm which of these systems will be the system of record before the first assessment, because assessors will ask how the records tie back to individual devices.

How an assessor tests SR-9

This table maps each SP 800-53A examine object for SR-9 to the evidence an assessor asks for, how the test is run and the findings that usually appear. Read it as the assessor's checklist: the single determination statement is satisfied only when the program, its tools and the acquisition records line up.

Examine object	Evidence requested	Test approach and common findings
Tamper protection program documentation	Written tamper protection program covering the system, components and services, with defined roles and life cycle stages	Assessor checks that the program names owners and stages. Common finding: a program that exists only on paper, with no evidence it has run.
Tamper protection tools and techniques documentation	Inventory of the tamper protection methods in use, such as seals, tamper-evident packaging, firmware or configuration checks	Assessor compares the listed techniques with what is deployed. Common finding: tools are listed but not configured or not applied to the components in scope.
Tamper resistance and detection tools and techniques documentation	Description of detection methods, alert paths and records of checks run across the life cycle	Assessor looks for detection outputs such as file integrity reports or inspection logs. Common finding: detection is described but no results or responses are retained.
Acquisition documentation	Purchase records and contract terms showing tamper protection requirements for delivered components	Assessor traces a sample of acquisitions to the tamper checks applied on receipt. Common finding: no link between acquisition and tamper checks, so components are accepted without verification.
Interview method	Discussions with program owners, procurement and receiving staff about how checks are performed and escalated	Assessor confirms that staff describe the same process as the documents. Common finding: staff are unaware of the program or describe different steps.
Test method	Sample of components with recorded tamper checks, plus results of any detection tool runs	Assessor selects components and verifies the recorded check against the program. Common finding: gaps in the sample record or checks completed without documented results.
SR-9(1) multiple stages (high baseline)	Records showing tamper protection applied at more than one stage of the life cycle	Assessor confirms checks at separate stages, such as receipt, deployment and maintenance. Common finding: checks happen once at delivery and are never repeated.

How to build a tamper protection program in order

This sequence turns SR-9 from a policy statement into a working program: a defined scope and owner, chosen techniques for each component type, checks at acquisition and receiving, baselines on deployed systems, a documented response to detected changes, and a periodic review that an assessor can trace from start to finish.

Define program scope and owner
Name the accountable owner for the tamper protection program and list the systems, system components and system services it covers, including hardware, firmware, software and any services that touch them. Record which life cycle stages apply, from acquisition through operation and disposal. Scope usually follows the system boundary in the system security plan, so the two documents must agree. The output is a signed program charter that names the owner, the covered inventory and the stages in scope. An assessor will ask for this charter first, because SR-9 is assessed against tamper protection program documentation.
Select techniques for each component type
Group the in-scope inventory by component type, such as servers, network devices, endpoints, removable media and firmware-bearing devices, and choose the tamper resistance and detection techniques suited to each group. Some techniques prevent alteration, such as physical seals, secure boot and signed firmware, while others detect it after the fact, such as file integrity monitoring and hash comparison. Document why each technique fits each group and which owner runs it. The output is a tamper protection tools and techniques document that maps each component type to its controls. Confirm with each vendor which of these features their products support, rather than assuming them.
Tie checks to acquisition and receiving
Connect the program to procurement and receiving so that tamper checks begin before a component enters the environment. Add inspection requirements to purchase orders and contract clauses, define what receiving staff verify on arrival, such as seal integrity, packaging and serial numbers, and record the results against the asset record. Where a component is delivered in a sealed or verifiable state, record the expected state so later checks have a reference. The output is acquisition documentation that references the tamper checks and a receiving record for each delivery. Assessors examine this acquisition documentation as part of SR-9.
Capture baselines on deployed systems
After a component is installed and configured in its approved state, capture a baseline of the files, configurations, firmware versions and hashes that define it. Store the baseline outside the system it describes, so an attacker with access to the system cannot rewrite it. Use inventory tooling such as an asset register or endpoint inventory to tie each baseline to a specific asset. The output is a set of recorded baselines, each dated, approved and linked to an asset identifier. Without a trusted baseline, detection later has nothing to compare against.
Run detection and compare against baselines
Schedule detection so that deployed components are checked against their baselines on a defined cycle and after events such as maintenance visits or relocations. Integrity monitoring tools can watch key files and directories, record changes with the action, time and path, and calculate hashes of changed files. Backup verification jobs can also compare current files against cataloged attributes. Confirm each tool's coverage and log retention before relying on it. The output is detection logs and comparison reports that show what was checked, when and with what result.
Define the response to a detected change
Write a response procedure that states who receives an alert, how the change is verified, when a component is isolated or removed from service, and how the matter is handed to incident response. Include a rule for deciding whether a change is authorized, such as a matching approved change record. Record every alert, its verification outcome and the action taken. The output is a documented response procedure and a set of worked alert records. Assessors check that detected changes lead to a defined action rather than being logged and ignored.
Document and review the program
Assemble the charter, technique documents, acquisition and receiving records, baselines, detection reports and response records into one program file. Set a review cycle, record each review and its findings, and update the program when inventory, components or tools change. Tie the review to the organization's broader supply chain risk management plan and to the system security plan. The output is a current program file with dated review records. Assessors use this file to confirm the program is in operation, not only designed.

Evidence that passes an SR-9 assessment

An assessor testing SR-9 examines documents and tool records, then checks that they match how the system is actually protected. The cards below cover the artifacts that map to those examine objects, plus the acquisition and inspection records that show tamper protection carries through purchasing and operations. Each one needs a review date and a change trail so it still describes the system at assessment time.

Tamper protection program document

This is the written program that defines how tamper protection applies across acquisition, delivery, installation, operation, maintenance and disposal. For SR-9, it is the first examine object an assessor reads, so it must name the components in scope, the owner of each protection step and the events that trigger an inspection. Keep a document owner, a review date and a revision history, and confirm that each change is approved and dated. A program that has not been reviewed since its first release will be questioned, even if the controls are working.

Tamper resistance tools documentation

This artifact describes the mechanisms that make tampering harder, such as sealed enclosures, secure boot settings, signed firmware and restricted physical access to hardware. The assessor compares these records with the systems actually deployed, so each entry should name the component type, the protection in place and the configuration baseline it belongs to. Record changes whenever a hardware model, firmware version or sealing method changes, and keep the configuration exports that prove the protection is enabled.

Tamper detection tools documentation

This artifact covers how the organization notices that a component has been altered, which is distinct from preventing the change. Typical tooling includes file integrity monitoring and inventory reconciliation, and the documentation should state what is monitored, how often, and who receives alerts. Open-source options such as osquery file integrity monitoring write changes to a file_events table with the action, time and path, so the rule set and the retention of those events become evidence. Confirm alert routing and test it at least once per review cycle.

Acquisition documentation for tamper protection

Acquisition records show that tamper protection was requested before a purchase, not added after delivery. Assessors look for tamper requirements in solicitations, contract clauses, bills of materials and acceptance criteria, and for evidence that these were checked at receipt. Keep the signed contract language, the supplier's tamper evidence statements and the receiving inspection checklist together, with a date for each. Review these records when a supplier changes or a product line is refreshed, because older purchase terms may no longer match the hardware delivered.

Inspection and integrity check records

These are the dated results of physical and logical inspections, such as checks of seals and chassis when a device returns from travel or a high-risk location, and the automated integrity scans run on a schedule. Each record should identify the component, the inspector or tool, the result and the action taken for any exception. Retain integrity reports and exception tickets for the period your assessment requires, and reconcile them against the asset inventory so every in-scope component has a current entry.

Asset inventory linked to inspections

An inventory tied to inspection history lets an assessor pick any in-scope component and trace its tamper protection from purchase to present. GLPI's Assets module can record computers, network equipment, peripherals and racks, entered manually or pushed by the GLPI Agent, which gives a place to log the seal status and last inspection date. Wazuh Syscollector can add hardware and software inventory from endpoints. Confirm that the inventory is updated at each inspection and that removed items are marked so their records remain traceable.

What meeting SR-9 costs in money and effort

This table breaks the cost of an SR-9 tamper protection program into components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. No prices or durations are supplied for this control, so use the drivers and quote requests to compare offers on your own scope. The main takeaway is that licence spend can be removed with self-hosted open source, but design, baseline capture, inspection labor and evidence upkeep remain.

Cost component	One-time or recurring	What drives it and how to reduce it
Program design and documentation (tamper protection program, life-cycle stages, roles)	One-time, then reviewed periodically	Drivers: number of system types and suppliers in scope. Reduce by reusing one program across similar components and aligning it with SR-2 and SR-3 documents.
Tamper detection tooling and licenses	Recurring if commercial, often none for open source	Drivers: number of endpoints and whether commercial products are chosen. Self-hosted tools such as Wazuh, osquery and GLPI remove license spend, but hosting and administration remain.
Engineering time to capture baselines and file integrity rules	One-time initial build, recurring on change	Drivers: number of monitored paths and components, and how often they change. Reduce by limiting monitoring to high-value files and documenting approved change windows.
Integration of alerts into incident and ticketing workflows	One-time, then recurring tuning	Drivers: alert volume and number of receiving teams. Reduce by agreeing alert thresholds and routing before go-live.
Physical and logical inspection labor (SR-10 overlap)	Recurring, per inspection cycle	Drivers: device count, travel or high-risk return events, and inspection depth. Reduce by defining risk-based triggers and recording results in the asset inventory.
Evidence upkeep (tamper protection documentation, inventory and alert records)	Recurring	Drivers: assessment frequency and audit scope. Reduce by generating reports from the inventory and monitoring platform rather than compiling them by hand.
External review and assessor sampling	Recurring, per assessment cycle	Drivers: assessor sampling choices, FedRAMP or agency requirements, and sample size. Ask the assessor to state its sampling approach before the engagement starts.
Quote request	Not applicable	Ask for a written scope listing components, environments, monitoring tools, inspection triggers, evidence outputs and assumptions, plus separate line items for one-time and recurring work. No figures are given on this page.

Open-source tools that produce tamper detection evidence

Each tool below covers a different part of a tamper protection program: recording what components exist and where they are, detecting changes on endpoints, and comparing files against known-good attributes. None of them performs physical inspection or replaces a documented tamper protection program, so each card names the limit the reader should confirm before relying on it.

GLPI asset records

GLPI's Assets module tracks computers, network equipment, peripherals, printers, phones and racks, entered manually or pushed by the GLPI Agent through native inventory. For SR-9, the useful evidence is a register that ties each component to its acquisition record, its assigned location and its custodian, so an assessor can see what should be present and where. Confirm that your team keeps acquisition fields and location history current, because a register that is updated only at purchase cannot show when a device moved or was opened. GLPI does not detect tampering by itself.

Wazuh Syscollector inventory

Wazuh's Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups from each endpoint and stores them in the Wazuh indexer. Comparing successive snapshots can reveal an unexpected interface, service or account on a component that should be fixed in configuration. Confirm the collection interval, the retention period in your deployment and who reviews the differences, since an inventory no one compares produces no tamper finding.

Bareos verify jobs

Bareos verify jobs compare files on a system against attributes recorded in the backup catalog from an earlier run, which gives a Tripwire-like check for changes after a suspected break-in. For SR-9, this supports evidence that firmware images, configuration files and system binaries on sampled components still match their cataloged state. Confirm which paths are covered, that the catalog itself is protected from alteration, and that a verify failure triggers a documented investigation rather than a silent re-baseline.

osquery file integrity monitoring

osquery watches the files and directories listed under file_paths in its configuration and records each change in the file_events table with the action, time and path. Where possible it also calculates MD5, SHA1 and SHA256 hashes of changed files, which gives a traceable record of what changed and when. For SR-9, this supports near real-time detection of changes to protected paths on components. Confirm that the monitored paths match your tamper protection scope and that the configuration itself is under change control, because an unmonitored path produces no event.

Who owns SR-9 and what partners can take on

Your organization owns SR-9. The control asks for a tamper protection program across the life cycle of the system, its components and its services, and that program has to be defined, approved and run by people accountable for it. Decisions about which components are high risk, which inspection points apply, what counts as a tamper signal and who responds to it stay with your security and supply chain functions. A partner can build the tooling, but it cannot make those decisions for you.

Program ownership: Name an accountable owner for the tamper protection program and document how it links to the supply chain risk management plan and acquisition process.
Risk-based scope: Decide which components, locations and suppliers fall under the program, including components that travel or are deployed in high-risk locations.
Response decisions: Define who triages a tamper signal, who can quarantine a component and when a supplier must be notified.
Acceptance of residual risk: Management signs off on which detection gaps remain and how they are tracked.
Ongoing operation: Staff the monitoring, reviews and updates that keep the program current after go-live.

Before engaging anyone, confirm internally who owns each of these decisions and where the SR-9 evidence will be stored.

Where SR-9 programs usually fall short

Most SR-9 findings are not missing tools. They are gaps between the tamper protection program, the acquisition process, the detection tooling and the people who must act on alerts. The cards below describe the gaps assessors most often raise and the closing action for each.

Program not tied to acquisition

The tamper protection program exists as a document, but purchasing, receiving and vendor onboarding never invoke it. Assessors look for acquisition documentation that references tamper protection requirements for hardware, firmware and services, because SR-9 assessment includes that documentation as an examine object. Closing action: add tamper protection requirements to the procurement checklist and to the SR-5 contract clause set, then keep a dated record of which purchases were checked against them.

No baseline to compare against

Detection is only meaningful when the organization can show what a healthy component looked like on arrival. Many programs have no recorded configuration, hash set or inventory snapshot for servers, network devices or endpoints, so a change cannot be proven. Closing action: capture a baseline at provisioning and after each approved change, store it outside the monitored host, and confirm that file integrity tools such as osquery file integrity monitoring point at the paths the baseline covers.

Detection without an owner

Alerts about changed files or unexpected hardware reach a shared mailbox or dashboard that nobody is assigned to triage. Assessors ask who reviews tamper-related events, how quickly they are escalated and whether the decision is recorded. Closing action: name an accountable owner for each detection source, write a short response procedure that links to the incident response plan, and test it once with a simulated change.

Firmware changes outside the program

Firmware, BIOS, baseboard controller and network device updates often run through vendor tools or out-of-band consoles that the host-level monitoring never sees. An integrity check that covers only the operating system leaves the most privileged layer unobserved. Closing action: bring firmware version and hash records into the inventory, add firmware updates to the change process, and ask each vendor which integrity verification features its devices provide before relying on them.

Inventory that does not match reality

Tamper detection assumes the organization knows which components exist. When asset records lag behind racks, spares and returned devices, monitoring silently skips hardware that was added or swapped. Assessors often compare the inventory with a sample of physical or logical components. Closing action: reconcile the asset inventory against the monitoring agent deployment each quarter, and flag any system that reports no inventory or integrity data.

No evidence of review

A program that runs continuously but leaves no record of review is difficult to assess. Logs of alerts, decisions to close them and results of inspections are the artifacts that show the program operates as designed. Assessors typically request samples over a period rather than a single screenshot. Closing action: schedule a documented review of tamper alerts and integrity reports, retain the review records with the plan of action and milestones, and confirm the retention period with your assessor before the assessment begins.

Questions buyers ask about SR-9 cost, effort and help

What drives the effort of meeting SR-9 tamper resistance and detection?

The effort depends mostly on how many system components, system services and physical locations fall under the tamper protection program, and on how much of that inventory is already documented. SR-9 asks for a tamper protection program across the life cycle of the system, component or service, so the work starts with deciding which assets are in scope and who is responsible for each one. Hardware that ships, is stored, is installed and is repaired in different places creates more handoffs than a single data center. Cost components include internal staff time for policy, procedure and inventory work, any vendor or logistics costs for inspection and seals, and an independent assessor's fee for testing the program. Ask any partner for a written scope that lists the asset classes, sites and life-cycle stages covered before you accept a quote.

Can an organization implement SR-9 in-house without an outside partner?

Yes, an organization can implement SR-9 with its own staff, because NIST describes the Rev. 5 controls as flexible and implemented through an organization-wide risk management process rather than through a prescribed vendor product. The organization owns the control, so it can write the tamper protection program, assign roles and keep the evidence itself. In-house teams usually struggle with the parts that cross departments, such as procurement, receiving, logistics and field service, and with keeping inventory current over time. An outside partner can prepare systems and evidence, but the organization still owns the control and the decisions behind it. Confirm with your assessor which artifacts they expect before you decide who will write them.

What does SR-9 require from an internal team day to day?

The internal team needs clear ownership of the tamper protection program, a named owner for each asset class, and a routine for checking that the program runs as written. Day-to-day work includes maintaining the inventory of in-scope components, recording inspections and detected changes, and coordinating with acquisition and supply chain staff when equipment arrives. Engineers need to know how detection is configured and how alerts are triaged. Expect a recurring workload, not only a one-time project. Helpful internal skills include configuration management, asset management and incident handling. If those teams are stretched, the program will drift, and an assessor will see gaps between the written procedures and what people actually do.

How does the high baseline change the SR-9 work?

SP 800-53B assigns SR-9 to the high security control baseline, and in that baseline the enhancement SR-9(1) is also selected. Under the high baseline, the organization must address both the base control and the multiple-stages enhancement, which asks for tamper protection across more than one stage of the life cycle. That means evidence has to show protection at several points, such as acquisition, storage, transport, installation and maintenance, rather than at one checkpoint. Systems categorized at the high impact level therefore need broader documentation and more frequent evidence collection than a moderate system. Confirm with your assessor how they will sample across stages before you size the work.

How does FedRAMP Class D affect SR-9 for cloud providers?

FedRAMP's Rev5 baselines require SR-9 and SR-9(1) at Class D, so a cloud service that seeks FedRAMP authorization at that level must meet both. The requirement sits on top of the high baseline logic, which means the cloud provider needs multi-stage evidence that a federal assessor can test. Providers should check the current FedRAMP reference and their authorizing agency's requirements before scoping, because the Class D requirements are set by the FedRAMP program and not by NIST. Cost rises when a provider must extend tamper controls to hardware owned by subcontractors or colocation facilities, so include those parties early in scope discussions.

What does an implementation partner deliver, and what does the auditor still decide?

A partner typically delivers a written scope, a configured inventory and detection setup, procedures and templates, and an evidence package mapped to the SR-9 assessment objects. Fixed-scope engagements set those deliverables and timelines in writing before work starts. DeployOpen prepares systems, controls and evidence for compliance assessments, and it does not issue audit reports, attestations or certifications. The independent assessor decides whether the program meets SR-9 and SP 800-53A's examine, interview and test methods. The organization owns the decision to accept residual risk and the control itself. Ask any partner to state which items it will not perform, and ask your assessor to confirm the evidence they will accept.

Which open-source tools can produce SR-9 evidence, and what do they not prove?

Several self-hosted open-source tools can produce useful evidence for parts of SR-9. GLPI's Assets module records computers, network equipment and other hardware, which supports the inventory of in-scope components. Wazuh's Syscollector collects hardware, software and configuration data from endpoints into an indexer that supports inventory reports. Bareos verify jobs compare files against previously cataloged attributes, and osquery's file integrity monitoring records changes with action, time and path. These tools show configuration and change history, but they do not prove physical tamper protection, supplier-side controls or inspection outcomes. Confirm with your assessor which parts of the program they expect to see as procedures, records or physical inspections.

How DeployOpen scopes and prepares SR-9 evidence

DeployOpen works on SR-9 as an implementation partner: it prepares the tamper protection tooling, procedures and records inside your own infrastructure so your organization owns the control and can show evidence to an assessor. DeployOpen does not issue assessment reports or certifications; independent assessors do.

How we scope

Confirm which systems, components and services fall under the high baseline and need SR-9 and SR-9(1) evidence.
Agree in writing which life-cycle stages the tamper protection program covers, from acquisition through disposal.
Define which tamper detection tools, such as file integrity monitoring, are in scope and where they run in your environment.

How we build

Deploy self-hosted tooling such as osquery file integrity monitoring and Wazuh inventory inside your own cloud accounts or data centers.
Configure file_paths monitoring and inventory collection for the components named in the agreed scope, then test that changes are recorded.
Set up Bareos verify jobs to compare files against cataloged attributes, so changes after a break-in can be identified.

How we hand over

Document the tamper protection program, tool configuration and procedures in a form your assessor can examine.
Map each deliverable to the SR-9 examine objects in SP 800-53A, including acquisition documentation, so gaps are visible before assessment.
Provide runbooks and records that show how detections are reviewed and escalated, with an agreed handover checklist.

How we support

Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
Review tooling and configuration when the environment changes, so evidence stays current for the next assessment.
Confirm with your assessor which evidence they accept for SR-9 and SR-9(1) before the written scope is finalized.