Questions and answers

Use criticality analysis to identify the systems and components where counterfeit or tampered items could create unacceptable mission, safety, availability, confidentiality, or integrity impact. NIST's SR-11 guidance calls for coordinated anti-counterfeit policies and procedures and, where appropriate, qualified bidder or manufacturer lists and authorized suppliers. SR-11(3) says enterprises should conduct anti-counterfeit scanning for critical components at a minimum.

Prevention also includes tamper resistance and detection for critical components (SR-9), inspection before use and periodically afterward (SR-10), controlled service and repair (SR-11(2)), and contract flow-down where relevant. The organization must still tailor methods to the item and threat; the publication does not prescribe a single test, universal reporting destination, certification, or fixed inspection frequency for every organization.

Obsolete parts are a common borderline case. NIST's telecommunications example considers an original component that is no longer produced, a costly redesign, and purchases from the secondary market. The example uses trained physical inspection, digital imaging, signature and serial or part-number verification, sample electrical testing, design redundancy, and alternative vetted sources. These are illustrative controls, not a universal checklist or proof that every secondary-market item is counterfeit.

When authenticity is in doubt, stop the item from entering or remaining in production until the authorized decision-maker resolves its status. Follow applicable legal, regulatory, contractual, safety, evidence-handling, and reporting procedures rather than assuming that one NIST process fits every sector.

Evidence should connect the exact item to its claimed source and verification result and show how suspected or confirmed counterfeits were controlled. A general supplier certificate does not establish the identity of a delivered part when it cannot be matched to the part, lot, serial number, shipment, or other item-level record.

Identify the mission, business process, system, data, facility, or safety function that depends on the supplier. Then assess the supplied product or service, the consequence and time to unacceptable harm if it fails or is compromised, access and change authority, concentration and sub-tier dependencies, recovery time, and whether a qualified alternative can replace it in time. A small specialist, open-source maintainer, cloud subprocessor, or sole manufacturer can be critical even when direct spend is low.

NIST SP 800-161 Rev. 1 Update 1 says to maintain a current inventory of supplier relationships, contracts, products, and services and map them into organization-defined strategic groupings. It gives strategic/innovative, mission-critical, sustaining, and standard/non-essential as examples. The mapping should focus analysis on suppliers of the greatest strategic or operational importance and identify products and services that need greater confidence in risk mitigation, including single-source exposure.

Criticality and supplier risk answer different questions. Criticality measures the importance of the dependency and potential impact; the supplier risk assessment considers threats, vulnerabilities, likelihood, existing assurance, and other context. A well-controlled supplier may remain critical, while a non-critical supplier can still present risk that requires action.

Keep the evidence tied to the supplier inventory and the dependency being rated. A reviewer should be able to reconstruct why the supplier was classified as critical or non-critical, which assumptions were used, who approved the result, and which treatment changed because of it.

Do not infer low criticality from low spend, a successful questionnaire, or the existence of a contract. Record unresolved sub-tier visibility and alternative-source assumptions instead of treating missing information as evidence of low dependency.

Start from a documented baseline: the supplier and supplied product or service, supported mission and systems, criticality, access, data, sub-tier dependencies, contract requirements, assessed risks, accepted exceptions, and expected controls. Without that baseline, a new signal cannot be evaluated against the original decision.

NIST's Monitor step separates three questions. Compliance monitoring asks whether processes and supplied products or services meet established requirements. Effectiveness monitoring asks whether the requirements produce the intended risk result. Change monitoring looks for conditions that require different controls or a new risk decision.

Use both regular reviews and off-cycle triggers. NIST leaves the interval to the enterprise. Relevant signals can include vulnerabilities, incidents, failed controls, stale evidence, ownership or location changes, subcontractor changes, product updates, service degradation, end-of-life notices, supply concentration, and geopolitical or environmental changes. Define who evaluates each signal and who can require remediation, invoke continuity measures, accept residual risk, suspend use, or exit. A supplier's passing score at onboarding does not remain current when the product, threat, dependency, or evidence changes.

Evidence should show the monitored scope, expected supplier behavior, signals received, evaluation, decision, owner, and follow-up. A dashboard, subscription, or annual questionnaire proves that data can be collected; it does not prove that someone evaluated the signal or changed the risk treatment when needed.

NIST's SR-4 guidance says provenance should be documented for systems, system components, and associated data throughout the system development life cycle. Choose the depth from criticality, threat, vulnerability, impact, and the decision the evidence must support.

For hardware, useful evidence can include the manufacturer and authorized distribution path, part, lot, and serial identifiers, chain of custody, transport and storage records, service and repair history, authenticity or acceptance tests, and tamper inspection. For software, it can include source repository and build identity, dependencies, signed releases, hashes, build or source attestations, and a software bill of materials (SBOM). For associated data, record the source, collection or creation process, transformations, custodians, integrity protection, and version or time period needed for the decision.

Bind the evidence to the exact product, component, release, build, or data set being accepted. Verify signatures and hashes with trusted reference information where applicable. Record gaps and uncertainty: a supplier statement may inform a decision, but it does not provide the same assurance as evidence whose identity, integrity, and relationship to the delivered item can be independently checked.

Keep the evidence attached to the exact item and version accepted. The record should let a reviewer reconstruct the claimed origin, authorized path, changes, custody, verification, exceptions, and approval decision. Preserve the verification inputs as well as the result; a bare status of 'verified' does not show what was checked.

NIST SP 800-161 Rev. 1 Update 1 says contracts and contract management should define vulnerability, incident, and business-disruption reporting and the parties' roles in response, corrective action, and recovery. Its SR-8 guidance also addresses notification agreements within the supply chain for critical products or services.

NIST SP 800-61 Rev. 3 supplies the incident-response structure: reports are validated, categorized, prioritized, and escalated; investigations establish what happened and preserve records; response activities are coordinated with internal and external stakeholders; incidents are contained and eradicated; and recovery is verified before normal operation is confirmed.

The organization remains responsible for its own decision. A supplier's statement that an incident is contained does not establish the scope or safety of the customer's environment. Determine which product versions, services, credentials, data, systems, customers, and sub-tier providers are affected, then decide what independent validation is needed. If the report remains unconfirmed, preserve that uncertainty, apply proportionate interim controls, and set the next decision time instead of treating silence as closure.

Use the evidence-preservation procedures and retention rules in the incident-response plan. NIST SP 800-61 Rev. 3 says incident data and metadata should be collected with their integrity and provenance preserved, while recognizing that formal chain-of-custody handling may not be necessary for every incident.

For a supplier incident, preserve enough evidence to support scope, containment, notification, recovery, and follow-up decisions. Record what the supplier reported, what the organization independently observed, where the accounts differ, what remains unknown, and who accepted any decision made with incomplete information.