NIST Privacy Framework, Protect-PPR.AC-P1

Do not manufacture or supply a consumer grade smart device with a universal default password from 4 March 2026 for a product manufactured on or after that date; the device's hardware and any pre-installed or required software must use a password unique to that unit or set by the user, for every state other than the factory default.

Do not ship the device with weak, blank, or identical-across-all-units default credentials, and do not derive an initial password from information easy to obtain by scanning network traffic, such as a MAC address; alternatively, force the user to set a new password meeting the strength rules the first time the device is used or after a factory reset.

Print any factory-set password on a label on the device and restore it whenever the device is reset to factory settings; require any user-set password to be at least 8 characters with an uppercase letter, a lowercase letter, a number, and a special character, and check new passwords against a password dictionary or an equivalent method to block weak or commonly used ones.

Where the device authenticates outside a local area network, give each unit a unique preprogrammed password or require the user to generate a new means of authentication before first use; meeting a NIST-conforming Internet of Things cybersecurity labeling scheme's baseline criteria and conformity assessment is an alternative way to satisfy the duty.

Ban universal default passwords and easily guessable passwords across the product's hardware and pre-installed or required software; a password must be unique per unit or set by the user, and must not be built from incremental counters or from publicly derivable identifiers.

Adopt measures that mitigate the risk that authentication elements categorized as knowledge are uncovered by or disclosed to unauthorized parties, that elements categorized as possession are used by or replicated for unauthorized parties, and that elements categorized as inherence and read by access devices and software are uncovered by unauthorized parties, with a very low probability of an unauthorized party being authenticated as the payer. Ensure that the breach of one element does not compromise the reliability of the others, and where an element is used through a multi-purpose device, use separated secure execution environments and mechanisms to ensure the software or device has not been altered (Articles 6 to 9).

Ensure the confidentiality and integrity of the personalized security credentials of the payment service user, including authentication codes, during all phases of the authentication: mask them when displayed, do not store them or the related cryptographic material in plain text, protect secret cryptographic material from unauthorized disclosure, document the management of the cryptographic material, and process and route credentials and codes in secure environments in accordance with strong and widely recognized industry standards (Article 22).

If you use passwords as a method of authentication, implement a written password policy that meets industry standards.

If you are a Class A company as 23 NYCRR 500.1(d) defines it, monitor privileged access activity and implement a privileged access management solution and an automated method of blocking commonly used passwords for all accounts on information systems you own or control and, wherever feasible, for all other accounts; where you determine that blocking is infeasible, your Chief Information Security Officer may instead approve in writing, at least annually, the infeasibility and the use of reasonably equivalent or more secure compensating controls.