YubiKey PIV security depends on slot policy, not model alone
A YubiKey PIV deployment can look consistent at the hardware layer and still have weak operational controls. The device exposes slots for authentication, signing, and key management. Each slot can carry a certificate and key, plus policies that control when a PIN is required and whether a physical touch is required. Those policies are part of the credential's security model.
Yubico recommends changing the PIN, PUK, and management key from their defaults before use. The management key authorizes administrative operations such as generating or importing keys into PIV slots. The PIN protects normal use, and the PUK supports a reset path when the PIN is unavailable. Leaving factory values in place makes possession of the device a much larger part of the authentication story.
The policies are set when a key is generated or imported. A sign or decrypt operation can require the PIN, and a touch policy can force a physical confirmation. The exact options depend on the YubiKey model and firmware. Review the actual metadata for each slot instead of assuming that a procurement standard configured every device in the same way.
Inventory slots and their purpose
Start with an approved slot map. Slot 9a is commonly used for PIV authentication, 9c for digital signatures, and 9d for key management. Organizations should document the certificate profile, algorithm, owner, relying party, and lifetime for each slot they use. A device that carries both an administrative signing key and an ordinary authentication certificate needs a different review from one used only for desktop login.
Record the PIN and touch policy for every populated slot. Confirm that a signing key used for release approval requires the intended confirmation. Confirm that a key used for unattended service operations has an explicit compensating control if its policy permits use without a touch. Do not disable a policy merely because a client application does not support it. Replace or redesign the client flow if the control is required.
The management key needs separate custody. It should be changed at provisioning and stored in a controlled recovery process. Shared default management keys allow another holder to alter slots or import a different key. If the organization rotates management keys, test the recovery path before changing the fleet. A lost management key can make a device difficult to administer even when the PIN still works.
Treat retry counters as availability controls
PIN and PUK retry counters are security features and operational constraints. Repeated failed PIN attempts can lock the PIN. A PUK reset can erase or reset protected state, depending on the device and command. Help-desk procedures must distinguish a forgotten PIN from a damaged device and must not encourage users to try a list of codes.
Test the recovery process on a spare device with the same firmware and certificate profile. Confirm what happens to keys, certificates, and audit records after a reset. Make sure the identity provider can revoke the old certificate and issue a replacement without reusing a stale slot profile. A recovery action that silently restores a broad management key is not equivalent to a controlled re-enrollment.
Verify the deployed state
A provisioning check should read device metadata and compare it with the approved profile. Check the serial number or asset identity, firmware version, populated slots, key algorithms, certificate subjects, PIN policy, touch policy, and management-key state. Store the result in the asset record. Do not rely on a one-time installation report that cannot distinguish a reimaged or replaced device.
For high-value keys, require a live operation test. Sign a test challenge, confirm the expected touch and PIN behavior, and verify the relying party rejects the result when the policy is wrong. Test a revoked certificate as well. The goal is evidence that the device, slot, application, and identity provider agree on the same credential.
Design for loss and compromise
Users should know how to report a lost or stolen key and how quickly the associated credentials are suspended. The response plan should identify every slot and relying party affected by one device. A device used for both VPN authentication and document signing creates two revocation paths. The incident owner needs to know which certificates belong to the same hardware.
PIV hardware improves resistance to key export when it is configured and operated correctly. The security claim rests on changed defaults, slot-specific policies, protected management keys, tested recovery, and a reliable revocation process. A model number alone does not establish those conditions.
