SR-11: Component Authenticity

To meet the sr-11: component authenticity requirement, you must establish and operate an anti-counterfeit program that prevents counterfeit hardware and software components from entering your systems, and can detect suspect components before deployment. Operationalize it by controlling sourcing, verifying authenticity at receiving and build time, documenting chain-of-custody, and escalating/quarantining anomalies with defined corrective actions. ¹

Key takeaways:

• Write an anti-counterfeit policy plus build/receive procedures that detect and block counterfeit components. ¹
• Make authenticity checks part of procurement, receiving, imaging/build, and incident response, not a one-time review.
• Evidence wins exams: show approved sources, inspection logs, traceability records, and disposition of suspect parts.

SR-11 sits in the NIST SP 800-53 Supply Chain Risk Management (SR) family and expects a real anti-counterfeit capability, not a policy binder. The operator outcome is simple: components that enter your environment (hardware, firmware, software, cloud marketplace images, replacement parts, even “new in box” spares) should come from controlled sources and pass repeatable authenticity checks before they can affect production. ²

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat SR-11 like a lifecycle control with four gates: (1) source control (who you buy from), (2) intake control (what you check when it arrives or is downloaded), (3) build/deploy control (what you verify before production), and (4) exception handling (how you quarantine and investigate anomalies). Then map each gate to an owner and recurring evidence so you can pass assessments without scrambling. ¹

This page gives requirement-level guidance you can assign to Procurement, IT, Security, and Engineering, with artifacts to collect and audit questions to anticipate.

Regulatory text

NIST SR-11: Component Authenticity requires you to: “Develop and implement anti-counterfeit policy and procedures that include the means to detect and prevent counterfeit components from entering the system; and” ¹

What the operator must do

• Develop: publish an anti-counterfeit policy and supporting procedures that cover the components you acquire, integrate, and deploy. ¹
• Implement: operate those procedures in day-to-day procurement, receiving, and deployment workflows. “Implemented” means staff follow the steps and you retain records that show the steps occurred. ¹
• Detect and prevent: add practical controls that (a) reduce counterfeit entry points and (b) flag suspect components early enough to avoid production impact. ¹

Plain-English interpretation

SR-11 expects you to treat counterfeit components as a supply chain threat with defined preventive and detective controls. “Counterfeit” in practice includes: unauthorized clones, tampered components, gray-market parts with unreliable provenance, modified firmware, and software packages/images that are not what they claim to be. Your program should make it hard for these components to enter, and easy for teams to identify, quarantine, and resolve them before deployment.

A common assessor expectation: you can explain, for your environment, what “authentic” means and how you verify it at the moment of acquisition and the moment of deployment.

Who it applies to

Entities

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 is flowed down contractually (common in federal contracting and regulated ecosystems). ²

Operational contexts (where SR-11 shows up)

• IT procurement and sourcing (OEMs, authorized resellers, marketplaces, brokers, cloud marketplaces).
• Data center and endpoint lifecycle (spares, replacements, RMAs, refresh projects).
• Software supply chain (installers, packages, containers, open-source dependencies, firmware updates).
• Third-party managed services (MSPs, hosting providers, integrators) when they supply components that become part of your system boundary.

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

Use this as an assignable runbook. Your goal is repeatable gates plus evidence.

Step 1: Assign ownership and scope the “component” universe

1. Name a control owner (often Supply Chain Security, GRC, or Security Engineering) and process owners in Procurement, IT Ops, and Engineering.
2. Define in-scope component types: hardware, firmware, software, images, libraries, replacement parts, security appliances.
3. Define system entry points: purchasing, downloads, third-party deployment, RMA/spares intake, M&A inherited assets.

Deliverable: SR-11 control statement mapped to owners, procedures, and evidence artifacts. ¹

Step 2: Write the anti-counterfeit policy (short, enforceable)

Your policy should answer:

• Approved sources: what sources are allowed (OEM/authorized reseller/contracted channels) and what sources require exception approval.
• Minimum verification: required checks at receiving and before production.
• Quarantine authority: who can block deployment, and under what conditions.
• Documentation: what must be recorded for traceability.
• Third-party expectations: contract clauses or purchase terms requiring provenance and cooperation with investigations.

Keep it specific enough that Procurement and IT can execute without interpretation disputes.

Step 3: Build preventive controls into procurement and contracting

Implement controls that reduce counterfeit likelihood:

• Approved supplier list with risk-based onboarding for new suppliers (including brokers).
• Purchase terms requiring authenticity attestations where feasible, traceability information (e.g., serials), and notification obligations for supply chain issues.
• No-direct-ship exceptions policy: when items ship outside standard receiving, require alternate verification.

Evidence focus: show that purchases route through approved channels or documented exceptions.

Step 4: Implement receiving and intake inspection (hardware + software)

At the point of entry, do checks that are realistic for your footprint.

Hardware receiving checklist (examples)

• Validate packaging integrity and tamper evidence.
• Verify serial numbers against purchase records and, where available, OEM validation tools.
• Confirm model/part numbers match the bill of materials and PO.
• Record chain-of-custody: who received it, where it was stored, and who released it to build.

Software intake checklist (examples)

• Require trusted sources (official repositories, approved mirrors, enterprise app catalogs).
• Validate integrity using hashes/signatures where your process supports it.
• Record version provenance (what was downloaded, from where, when, and by whom).

Note: SR-11 does not prescribe one technical method; it requires “means to detect and prevent.” Your procedures should match your risk and feasibility. ¹

Step 5: Add a “pre-production authenticity gate” to build/deploy

Counterfeit detection often fails when receiving is good but deployment bypasses controls (field installs, emergency changes, contractor work).

Minimum gate requirements:

• Deployment from approved inventory only (hardware) or approved repositories (software).
• No ad-hoc installs without ticketing and traceability.
• Configuration management linkage: assets/components installed map to an approved record.

Step 6: Define quarantine, escalation, and corrective actions

Write an exception workflow that staff can follow under pressure:

• Quarantine suspect components (physically isolate hardware; block software packages).
• Document indicators (photos, logs, validation failures, supplier info).
• Notify Security and Procurement; decide whether to open an incident or supplier dispute.
• Disposition: return to supplier, destroy, or retain for investigation.
• Root cause: how it entered, what control failed, what changes prevent recurrence.

Step 7: Train the doers and test the process

Training should be role-based:

• Procurement: approved sources and exception handling.
• Receiving/IT: inspection steps and quarantine triggers.
• Engineering: approved dependencies and build pipeline controls.

Test via tabletop exercises using a “suspect component” scenario. Your audit story improves when you can show the process works end-to-end.

Required evidence and artifacts to retain

Assessors usually ask for proof that procedures run consistently. Retain:

• Anti-counterfeit policy and detailed procedures for procurement, receiving, and deployment. ¹
• Approved supplier list and onboarding/approval records for suppliers and critical third parties.
• POs/invoices tied to assets and components.
• Receiving logs (inspection checklist completion, serial/part verification records, chain-of-custody).
• Software intake records (approved sources list, repository controls, package approval records).
• Exception approvals (who approved, rationale, compensating controls).
• Quarantine and disposition records (tickets, investigation notes, supplier communications).
• Training completion records for relevant roles.
• Internal audit/QA checks of adherence, plus corrective actions.

Practical tip: store artifacts by “gate” (Source, Intake, Deploy, Exceptions). This mirrors how assessors think.

Common exam/audit questions and hangups

Expect these questions and prepare direct evidence:

1. “Define a counterfeit component in your environment.” Show your policy definition and examples.
2. “How do you ensure purchases don’t bypass procurement?” Show purchasing controls and exception workflow.
3. “What do you check at receiving?” Provide the checklist and completed samples.
4. “How do you control software sources?” Show approved repositories, administrative controls, and sample approvals.
5. “Show a case where something was quarantined.” If you have none, show a test/tabletop record and your disposition workflow.

Hangup: teams claim “we only buy from reputable sellers” without showing approved-source controls and receiving evidence. SR-11 is evidence-driven. ¹

Frequent implementation mistakes and how to avoid them

• Mistake: Policy exists, procedures don’t. Fix: write checklists and make them part of tickets and receiving workflows so evidence is generated automatically. ¹
• Mistake: Hardware-only focus. Fix: include software packages, images, and firmware in scope; document how you control download sources and approvals.
• Mistake: Exceptions become the norm. Fix: require compensating controls and approvals for non-standard sourcing; track exceptions and review trends.
• Mistake: No chain-of-custody for spares and RMAs. Fix: treat returns and spare stock as high-risk intake; apply the same receiving steps.
• Mistake: Evidence scattered across teams. Fix: map SR-11 to an owner, procedure, and recurring evidence artifacts so you can produce a single assessment packet quickly. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SR-11, so this page does not cite enforcement actions.

Operationally, counterfeit components create two categories of risk you will be expected to manage:

• Security risk: tampered hardware/firmware/software can introduce hidden functionality or undermine integrity controls.
• Resilience and safety risk: counterfeit parts fail unpredictably, complicate incident response, and can trigger widespread replacement efforts.

SR-11 reduces these risks by requiring detection and prevention mechanisms as an operational program. ¹

Practical 30/60/90-day execution plan

Use phased execution without relying on calendar promises. The milestones below are outcome-based.

First 30 days (Immediate stabilization)

• Appoint SR-11 control owner and process owners; publish a one-page RACI.
• Draft anti-counterfeit policy and minimum receiving/deploy checklists for the highest-risk components.
• Stand up an approved-source rule in Procurement and an exception approval path.
• Define quarantine/disposition workflow and a single intake ticket type for suspect components.

By 60 days (Operationalize and generate evidence)

• Roll procedures into standard operating workflows (receiving tickets, build checklists, change management).
• Start collecting recurring evidence samples across hardware and software.
• Train Procurement, Receiving/IT, and Engineering teams; record completion.
• Run a tabletop: “suspect component discovered pre-deploy,” and capture corrective actions.

By 90 days (Harden and make it assessment-ready)

• Expand scope to remaining component classes and less common entry points (RMAs, field installs, third-party integrators).
• Implement periodic QA checks (spot checks of receiving logs and software intake records).
• Produce an assessor-ready SR-11 packet: policy, procedures, last evidence samples, and exception/quarantine examples.

Where Daydream fits (without adding process drag)

If you’re struggling with “missing implementation evidence,” Daydream is useful as the system of record that ties SR-11 to the control owner, the operating procedure, and the exact evidence artifacts you need on a recurring basis. That mapping is the difference between “we do this” and “here’s the proof.” ¹

Frequently Asked Questions

Does SR-11 apply only to physical hardware?

No. The requirement is about “components” entering the system, which in practice includes hardware, software, firmware, and images. Your scope statement should explicitly list what you treat as a component and how each is verified. ¹

We buy only from major resellers. Is that sufficient?

Approved sources help, but SR-11 also expects procedures that detect and prevent counterfeit components from entering the system. Keep receiving/intake checks and retain evidence that those checks occurred. ¹

What evidence do auditors usually want first?

They usually start with your policy/procedures and then ask for recent samples that show the procedures ran (receiving logs, approvals, exception handling). Prepare a small evidence packet organized by procurement, intake, deployment, and quarantine. ¹

How do we handle emergency purchases or field replacements?

Create an exception path with documented approval and compensating controls (enhanced inspection, verified serials, restricted deployment until validated). If emergencies bypass controls, they become a repeat audit finding.

What should we do if we suspect a counterfeit component is already deployed?

Treat it as a security and integrity issue: isolate where feasible, document indicators, open the appropriate incident or problem ticket, and coordinate with Procurement for supplier engagement. Update controls based on the root cause so the entry path closes.

How detailed should our anti-counterfeit procedure be?

Detailed enough that two different teams would perform the same checks and produce the same records. If the procedure can’t be audited through artifacts, it’s not detailed enough for SR-11. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5