Search every question across sub-FAQs

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.

Begin with a risk scenario that connects a threat event, vulnerability or exposure, affected supplier, product, service, or supply-chain path, likelihood, and impact. State the time horizon and assumptions. Consider criticality, concentration, substitutability, dependencies, recovery or replacement time, and effects on missions, systems, data, people, other organizations, and the Nation where relevant.

Compare responses against risk appetite and risk tolerance, mission priorities, applicable law and contracts, cost, feasibility, dependencies, and decision authority. Acceptance keeps the identified exposure without further risk-reducing action because the authorized owner judges the remaining risk acceptable. Avoidance removes the activity or exposure. Mitigation changes likelihood or impact through controls. Sharing or transfer reallocates some responsibility or financial consequence through arrangements such as contracts or insurance, but it does not automatically remove operational, mission, legal, or reputational exposure.

Mitigation can include alternate sources, contract changes, added inspection or testing, segmentation, reduced access, patching, inventory buffers, recovery measures, or increased monitoring. State which part of the scenario each action changes and how effectiveness will be measured. Listing controls without that connection does not explain the response.

The record should preserve the assessed scenario, source information, assumptions, alternatives, selected response, decision authority, residual risk, funded actions, dependencies, effectiveness measures, and current status. Link it to the relevant C-SCRM plan, risk register, system plan, supplier assessment, contract, contingency plan, incident record, or plan of action and milestones (POA&M).

Review the response at the planned interval and when a material change could alter likelihood, impact, effectiveness, or decision authority. NIST's Monitor step calls for organization-set review intervals and documented off-cycle triggers, not one universal cadence.

Triggers can include new threat or vulnerability information, an incident, failed control, stale evidence, supplier or product change, ownership change, loss of an alternative source, contract change, changed mission or architecture, audit finding, natural disaster, or resource change. Update the assessment and response rather than recording the trigger without a new decision.

Create organization-defined supplier categories using consistent criteria. NIST gives strategic/innovative, mission-critical, sustaining, and standard/non-essential as examples, not a required four-tier scale. These supplier groupings focus analysis and treatment; they do not replace a supplier-specific risk assessment. Relevant criteria include mission and system dependency, product or component criticality, access and data sensitivity, concentration and substitutability, geographic and ownership considerations, known threats and vulnerabilities, incident history, and potential business or safety impact. A low-spend sole-source component or service with privileged access can warrant the highest treatment even if the supplier is small.

Use the category to set due-diligence depth, required evidence, contract and flow-down terms, assessment method, monitoring interval and triggers, incident involvement, contingency planning, and approval authority. The category should reflect the dependency and exposure before considering assurance. A strong assessment result does not make a single-source, mission-critical dependency non-critical.

Record separately which risk-management level owns the decision. Level 1 sets enterprise strategy, governance, policy, risk appetite, and enterprise decisions. Level 2 tailors that direction to missions and business processes. Level 3 applies it to systems, procurements, and other operational work. The CSF Tiers describe the organization's broader practices and should not replace either field.

Keep the supplier category and rationale linked to the relationship inventory and the treatment it drives. Separately record the risk-management level that owns the decision and any CSF Tier used to characterize the organization's broader practices. This prevents a label such as 'Tier 2' from silently carrying three different meanings.