Stop using the PIV CHUID as a standalone door authenticator

Bottom line: the continued presence of a CHUID data object on a PIV card does not make CHUID a current standalone authentication mechanism. A legacy PACS may still read the field, so the system’s actual authorization logic must be inspected rather than inferred from credential format.

Source fact: FIPS 201-3 removed CHUID authentication

The online edition of FIPS 201-3 states that the CHUID authentication mechanism was removed. It also states that the CHUID data element remains mandatory because it supports other authentication mechanisms. FIPS 201-3 separately describes PIV authentication mechanisms and their assurance characteristics.

The distinction is precise: retaining a data object for compatibility or support does not authorize a PACS to treat an unauthenticated read of that object as proof that the presented card or presenter is valid.

Source boundary and applicability

FIPS 201-3 is a federal standard and must be interpreted with agency policy, current NIST guidance, and the deployed product documentation. The source does not prove that a particular reader uses CHUID alone, prescribe a universal migration date for every environment, or approve a replacement mechanism for each doorway. Nonfederal use should identify the governing requirement.

Applicability questions

• Which card object and authentication mechanism does each reader transaction actually use?
• Does the controller make a decision from a copied identifier without cryptographic card authentication?
• Can logs distinguish CHUID reads from PIV authentication mechanisms?
• Which panels, readers, middleware, and badge databases depend on legacy identifiers?
• What operational, accessibility, visitor, and emergency workflows would a migration affect?

DSE recommendation: trace the decision before changing it

The following steps are DSE recommendations based on the cited source.

Build a door-by-door inventory of reader model and firmware, credential technology, card object read, authentication operation, controller decision field, validation service, and logged result. Confirm behavior from configuration, vendor documentation, and a controlled test; a reader label that says PIV is insufficient.

Prioritize boundaries where a standalone CHUID decision controls meaningful risk. Select the required mechanism through the applicable risk and agency process, confirm end-to-end support, and pilot it with representative cards and failure states. Prevent silent fallback to CHUID-only access unless an explicitly authorized, time-limited degraded procedure exists. Protect egress and coordinate any live door change with responsible facility and life-safety personnel.

Verification and evidence

Retain the transaction-path inventory, vendor support statements, relevant policy decision, sanitized reader/controller traces, valid and invalid test results, fallback tests, change approval, rollback plan, user-impact record, and post-change access logs. Avoid placing full credential identifiers in broadly accessible reports.

Official references

• FIPS 201-3 – Personal Identity Verification of Federal Employees and Contractors – National Institute of Standards and Technology