Acquisition Process | Use of Approved PIV Products

To meet SA-4(10), your acquisition and engineering teams must buy and deploy only Personal Identity Verification (PIV) products that appear on the FIPS 201-approved products list for any PIV capability in your system. Operationally, this means putting a hard procurement gate in place, verifying approval before purchase, and retaining evidence that the deployed product matches the approved listing. (NIST Special Publication 800-53 Revision 5)

Key takeaways:

• Your procurement process must block non-approved PIV products from being purchased or renewed. (NIST Special Publication 800-53 Revision 5)
• “Approved” is not a marketing claim; you need objective confirmation that the exact product/version is on the FIPS 201-approved products list. (NIST Special Publication 800-53 Revision 5)
• Auditors will expect traceability from requirement → purchasing decision → deployment → inventory. (NIST Special Publication 800-53 Revision 5)

SA-4(10) sits in the System and Services Acquisition family, so it is less about how you operate PIV day-to-day and more about how you prevent the wrong technology from entering your environment in the first place. The requirement is narrow but easy to fail: if any part of your PIV capability depends on a product that is not on the FIPS 201-approved products list, you have a compliance gap. (NIST Special Publication 800-53 Revision 5)

For a Compliance Officer, CCO, or GRC lead, the fastest path to “operationalized” is to turn this requirement into a procurement control with engineering validation. That means: (1) define what counts as “PIV capability” in your architecture, (2) identify the products that provide it, (3) verify those products are approved, and (4) make approval verification a mandatory step before purchase, renewal, or major version change. (NIST Special Publication 800-53 Revision 5)

This page gives you requirement-level implementation guidance: who owns what, what to put in your acquisition workflow, which artifacts to retain, and the audit questions you should be able to answer without scrambling.

Regulatory text

Requirement (verbatim): “Employ only information technology products on the FIPS 201-approved products list for Personal Identity Verification capability implemented within organizational systems.” (NIST Special Publication 800-53 Revision 5)

What the operator must do:

• If your system implements PIV capability, you must ensure the IT products used for that PIV capability are on the FIPS 201-approved products list. (NIST Special Publication 800-53 Revision 5)
• This must be enforced through your acquisition process, not handled as an informal engineering preference. The control lives where purchasing decisions and renewal decisions happen. (NIST Special Publication 800-53 Revision 5)

Plain-English interpretation

If you use PIV (for example, smart card-based identity credentials) anywhere in your environment, you cannot choose “close enough” identity or card products. You must select products that are explicitly approved for FIPS 201 PIV, and you must be able to prove it. (NIST Special Publication 800-53 Revision 5)

Two practical implications drive most audit outcomes:

1. Exact-match validation: Approval must map to the specific product and its relevant version/build or configuration that you deploy, not a general vendor name. (NIST Special Publication 800-53 Revision 5)
2. Procurement gating: If your procurement and third-party intake workflows allow someone to buy a non-approved PIV-related product, the control is not operating effectively. (NIST Special Publication 800-53 Revision 5)

Who it applies to

Entity types: Cloud Service Providers and Federal Agencies implementing NIST SP 800-53 controls (including environments aligned to FedRAMP baselines). (NIST Special Publication 800-53 Revision 5)

Operational context:

• Applies when your system implements Personal Identity Verification capability. This typically includes PIV card issuance/management, card readers and middleware, authentication modules that validate PIV credentials, and any integrated components that provide PIV functions. (NIST Special Publication 800-53 Revision 5)
• Applies across the lifecycle: new purchases, renewals, replacements, and major upgrades that change the product/version used for PIV capability. (NIST Special Publication 800-53 Revision 5)
• Applies to third parties: if a third party provides PIV capability as part of a managed service you consume, you still need to validate the products used to deliver that capability. (NIST Special Publication 800-53 Revision 5)

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

1) Define “PIV capability” in your system boundary

Create a short, system-scoped definition that answers: “Which functions in our environment are considered PIV capability?” Then map it to components. Examples of component categories to enumerate:

• Credential issuance and lifecycle management tools
• Smart card readers and associated drivers/middleware
• Authentication/verification modules that validate PIV credentials
• Physical access integrations if they are in scope for the system boundary (only include if your authorization boundary includes them)

Output: PIV Capability Component Register (a list of in-scope products/components and owners). This makes audits faster because it shows you understand where SA-4(10) applies. (NIST Special Publication 800-53 Revision 5)

2) Identify current-state products and gaps

For each component in the register:

• Capture product name, publisher, version/build, deployment location, and the team that owns it.
• Record how it was acquired (purchase order, reseller, bundled service, subcontractor).

Then compare each product to the FIPS 201-approved products list status (approved/not approved/uncertain). Treat “uncertain” as a gap until resolved. (NIST Special Publication 800-53 Revision 5)

Output: SA-4(10) Product Approval Assessment (table) and a gap list.

3) Implement a procurement gate (the control that makes this real)

Update your acquisition workflow so that any request involving PIV capability cannot proceed without documented approval verification.

A workable gate has three parts:

• Trigger: Purchase, renewal, or major change request for any PIV capability component.
• Required check: Requestor must provide evidence the exact product is on the FIPS 201-approved products list.
• Approver: Security/GRC (or IAM security) must sign off before Procurement executes.

Practical way to operationalize:

• Add a required field to your purchasing intake form: “Is this product used for PIV capability?” with “Yes/No.”
• If “Yes,” require attachment: “FIPS 201-approved products list evidence.”
• Block PO issuance until the attachment and approval are present. (NIST Special Publication 800-53 Revision 5)

If you use a third-party risk process for product onboarding, route PIV products through a dedicated checklist so your third-party intake cannot bypass SA-4(10).

4) Contract and SOW language (minimum viable)

For purchases where a third party provides or embeds PIV capability, add terms that require:

• The third party will provide only products on the FIPS 201-approved products list for PIV capability used in delivering the service.
• The third party will notify you before changing the product/version used for PIV capability.
• The third party will provide evidence of continued approval upon request.

Keep this scoped. You are not trying to rewrite the entire MSA; you are making the approval status auditable. (NIST Special Publication 800-53 Revision 5)

5) Tie approval to deployment and inventory

Auditors often test drift: “You bought the right thing; did you deploy the right thing?”

Add two operational checks:

• Pre-deploy verification: Implementation ticket must reference the approved product/version.
• Inventory linkage: Your CMDB/asset inventory should record the PIV product/version so you can prove what is actually running.

Output: Configuration/Asset evidence that connects the approved listing to the deployed instance. (NIST Special Publication 800-53 Revision 5)

6) Handle exceptions explicitly (prefer “no exceptions”)

SA-4(10) is written as “employ only,” which does not read like an exception-friendly control. If your organization allows exceptions in general, treat PIV exceptions as high scrutiny:

• Require a compensating control proposal and a timeline to replace with an approved product.
• Route to the Authorizing Official (or equivalent governance body) for decision.
• Track to closure.

If you cannot get explicit risk acceptance, don’t buy it. (NIST Special Publication 800-53 Revision 5)

Required evidence and artifacts to retain

Retain artifacts that prove: (a) you checked, (b) you purchased accordingly, (c) you deployed accordingly, and (d) you prevent recurrence.

Minimum evidence set:

• Policy/procedure: Acquisition standard or secure procurement procedure with the SA-4(10) gate described. (NIST Special Publication 800-53 Revision 5)
• PIV Capability Component Register: in-scope systems/components list with owners. (NIST Special Publication 800-53 Revision 5)
• Approval proof: screenshots/PDF exports or other records showing the product is on the FIPS 201-approved products list (and matches the product/version you plan to use). (NIST Special Publication 800-53 Revision 5)
• Procurement records: purchase request, PO, invoice, or contract/SOW linking the acquired product to the approved product. (NIST Special Publication 800-53 Revision 5)
• Change records: tickets showing approval verification for renewals, upgrades, or replacements. (NIST Special Publication 800-53 Revision 5)
• Inventory/configuration evidence: CMDB entries, software inventory, or configuration baselines demonstrating the deployed product/version. (NIST Special Publication 800-53 Revision 5)
• Third-party attestations (if applicable): contract clause and communications showing third-party notification and evidence obligations. (NIST Special Publication 800-53 Revision 5)

If you use Daydream to run third-party due diligence and procurement readiness, store the approval evidence and the reviewer sign-off as structured artifacts attached to the third party and the product record. That makes it easier to show consistent gating across teams without chasing emails.

Common exam/audit questions and hangups

Expect questions like:

• “Show me all products that provide PIV capability in this system boundary and their approval status.” (NIST Special Publication 800-53 Revision 5)
• “Walk me through your purchasing workflow. Where is the control point that prevents buying a non-approved PIV product?” (NIST Special Publication 800-53 Revision 5)
• “This product was renewed last cycle. What evidence shows you revalidated approval before renewal?” (NIST Special Publication 800-53 Revision 5)
• “How do you ensure the deployed version matches the approved listing?” (NIST Special Publication 800-53 Revision 5)
• “If a third party provides PIV capability, how do you know they use approved products?” (NIST Special Publication 800-53 Revision 5)

Hangups that slow audits:

• Approval evidence exists but is not tied to a specific purchase or implementation ticket.
• Engineering knows the product is “approved,” but Procurement cannot show the gate.
• Inventory does not record versions, so you cannot prove the deployed state. (NIST Special Publication 800-53 Revision 5)

Frequent implementation mistakes (and how to avoid them)

1. Checking only at initial purchase
   Fix: require re-check at renewal and major version change through the same gate. (NIST Special Publication 800-53 Revision 5)

2. Assuming a vendor is approved, rather than a product/version
   Fix: make the evidence requirement “exact product match,” and train requestors to attach the listing proof. (NIST Special Publication 800-53 Revision 5)

3. Letting a third party’s managed service bypass scrutiny
   Fix: add contract language and an onboarding checklist item: “PIV capability provided? If yes, provide FIPS 201-approved product evidence.” (NIST Special Publication 800-53 Revision 5)

4. No system boundary clarity
   Fix: publish the PIV Capability Component Register and keep it aligned to your authorization boundary documentation. (NIST Special Publication 800-53 Revision 5)

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source catalog, so don’t plan on citing a headline case to justify urgency.

Your real risk is operational and authorization-based:

• Buying or deploying non-approved PIV products can create an authorization finding because it is a direct mismatch to the “employ only” requirement language. (NIST Special Publication 800-53 Revision 5)
• PIV sits in the identity and access path. Weaknesses here can undermine trust in authenticated access, which can cascade into broader control failures during assessment. (NIST Special Publication 800-53 Revision 5)

Practical execution plan (30/60/90-day)

Use these as phases. Adjust to your release cycles and procurement calendar.

First 30 days (Immediate)

• Assign an owner for SA-4(10) operations (often IAM security + Procurement ops).
• Draft the PIV Capability Component Register for the system boundary.
• Identify existing PIV products and label each as approved/not approved/uncertain based on documented evidence. (NIST Special Publication 800-53 Revision 5)
• Add a purchasing intake question and attachment requirement for PIV-related requests. (NIST Special Publication 800-53 Revision 5)

Next 60 days (Near-term)

• Update acquisition procedure language to include the SA-4(10) gate and approver role.
• Add contract/SOW clauses for third parties providing PIV capability.
• Implement pre-deploy verification in your change management workflow for PIV components.
• Backfill evidence for the highest-risk or most critical PIV components first (those that affect authentication into production). (NIST Special Publication 800-53 Revision 5)

Next 90 days (Operationalize and prove)

• Make the gate measurable: sample recent purchase/renewal tickets and confirm evidence is attached and approved.
• Align CMDB/software inventory fields to capture PIV product/version for deployed instances.
• Create an audit-ready package: register, approval evidence samples, and workflow screenshots showing the enforced gate. (NIST Special Publication 800-53 Revision 5)
• If you run third-party workflows in Daydream, standardize a “PIV capability” flag and require the approval evidence artifact before the third party can move to “approved for purchase.”

Frequently Asked Questions

Does SA-4(10) apply if we use PIV only for admin access and not for all users?

Yes. The requirement applies to any PIV capability implemented within the system, regardless of how many users rely on it. Scope it to the components that provide PIV functions. (NIST Special Publication 800-53 Revision 5)

What counts as “employ only” in practice?

Your acquisition process must prevent buying or deploying PIV-related products that are not on the FIPS 201-approved products list. Treat it as a hard gate with documented verification, not a best-effort check. (NIST Special Publication 800-53 Revision 5)

Can we rely on a reseller or third party’s assurance that a product is approved?

You can collect their assurance, but you still need your own retained evidence that the exact product used for PIV capability is on the FIPS 201-approved products list. Keep it tied to the purchase and deployment record. (NIST Special Publication 800-53 Revision 5)

What if the product is approved but our deployed version is newer than the listing evidence we saved?

Treat that as a compliance gap until you can show the deployed version matches an approved listing. Add version capture to inventory and require revalidation at upgrades. (NIST Special Publication 800-53 Revision 5)

We have a legacy PIV component that is hard to replace. How do we handle that?

Start by documenting it in the component register and determining whether you can obtain approval evidence for the exact product/version. If you can’t, route a formal exception through your risk acceptance governance and build a replacement plan. (NIST Special Publication 800-53 Revision 5)

What will an auditor accept as evidence?

Evidence that is specific, retrievable, and traceable: the approved listing proof, the purchasing record, and the deployed inventory/config proof. The most common failure is evidence that exists but cannot be linked end-to-end. (NIST Special Publication 800-53 Revision 5)