Does a certified product mean my deployment is certified?

No. A certificate applies to a specific product, version and configuration evaluated against a specific standard. Your deployment inherits that assurance only if you run the same version in the evaluated configuration, and your organization's use of it is a separate matter for your own audits.

Is it safe to buy security devices second-hand?

For anything that holds keys or protects evidence, no. You cannot verify the device's history or firmware, and some attacks rely on pre-tampered units. Second-hand test equipment such as oscilloscopes or logic analyzers is a different matter and often a good deal.

How many spares should we keep?

Enough to replace failures while a new order arrives, which depends on lead times. For authenticators, that means a second key per user plus a small pool for new starters and losses. For HSMs, it means a clustered or standby unit and a tested restore procedure.

Security hardware buying checklist for practitioners

The same device can be a sound control or a liability depending on how it was bought, delivered, configured and retired. This checklist applies to every category on this site, from a security key on a keyring to an HSM in a data centre and a write blocker in a forensic kit. It is deliberately vendor-neutral and contains no prices: prices change, the questions do not.

Step 1: write the threat model before the shortlist

Start with one paragraph per device class that answers:

What asset does the device protect (identities, keys, evidence integrity, network segments)?
Which attacks must it stop (phishing, key extraction after theft, host malware, tampering in transit)?
Which attacks are out of scope and handled elsewhere (coercion, insider misuse, physical theft of an entire rack)?
What is the operational cost you can accept (user friction, admin time, recovery procedures)?

A FIDO2 key chosen to stop phishing, an HSM chosen to meet a certificate policy and a write blocker chosen to support court testimony all need different evidence of quality. The threat model tells you which evidence to ask for.

Step 2: read certifications correctly

Scheme	What it evaluates	What to check
FIPS 140-3 (NIST CMVP)	Cryptographic module: algorithms, key management, roles, physical security at levels 1 to 4	Active certificate number, exact hardware and firmware versions, overall level, and the security policy's approved-mode configuration
Common Criteria (ISO/IEC 15408)	A product against a protection profile or security target at an assurance level (EAL)	Which protection profile or security target, which evaluation assurance level, which version, and which features were outside the target of evaluation
FIDO Authenticator Certification	Functional conformance and authenticator security level (L1 to L3+)	Level for your model and firmware in the FIDO Metadata Service
PCI PTS HSM	Payment HSM physical and logical security	Approval number and expiry
NIST CFTT test reports	Forensic tools against published specifications	A report for your model and firmware; read the anomalies section
EUCC (EU Common Criteria-based scheme)	EU cybersecurity certification for ICT products	Scheme level and certificate status

Common pitfalls:

"FIPS compliant" or "FIPS ready" is not "FIPS validated." Only a CMVP certificate counts.
A certified chip is not a certified product. A device may use a certified secure element while its firmware and other components were never evaluated.
Certificates expire or move to historical status. Check the status on the day you buy.
Updates can take a device out of its evaluated version. Ask the vendor how updates interact with certification.

Step 3: evaluate the design, not the brochure

Beyond certification, ask each vendor (and note who cannot answer):

Key generation and storage. Where are keys generated, can they be exported, and under what controls?
Firmware. Is it signed? Can it be updated? Is it open source or independently audited? How long are security updates promised?
Vulnerability handling. Is there a published disclosure policy, a security advisories page and a history of fixed issues? A vendor with no advisories is not necessarily a vendor with no bugs.
Attestation. Can the device prove its model and genuineness cryptographically (FIDO attestation, TPM EK certificates, HSM attestation, vendor genuineness checks)?
Interoperability. Which standards does it implement (FIDO2/CTAP, PKCS#11, KMIP, PIV, E01)? Proprietary-only interfaces create lock-in and migration risk.
Management at scale. Inventory, policy enforcement, logging and integration with your identity or SIEM tooling.
End of life. How much notice before end of sale and end of support, and how are keys migrated to successor models?

Step 4: control provenance

Most real-world attacks on security hardware happen before the device is used: counterfeits, tampered units and social engineering around delivery.

Buy from the manufacturer or an authorized distributor. Keep the list of authorized channels in your procurement system.
Avoid marketplaces and second-hand units for anything that holds keys or protects evidence.
Record serial numbers at receipt and compare them to the vendor's shipping information where available.
Inspect tamper evidence on packaging and devices, and photograph it for high-value items such as HSMs.
Verify genuineness cryptographically when the device supports it, before production use.
Initialize devices yourself. Reset authenticators, generate keys on the device, change default credentials, and never accept pre-provisioned secrets from a reseller.
Use tamper-evident bags and chain-of-custody forms for devices shipped between sites, just as you would for evidence.

Step 5: plan the lifecycle on day one

Phase	Questions to settle
Enrolment	Who initializes, who witnesses, where are records kept?
Operation	How is the device monitored, and who reviews its logs?
Updates	Who approves firmware updates, how are they tested, and how is rollback handled?
Loss and failure	What is the spare, how fast can it be deployed, and how is the lost device revoked?
Recovery	Where are backups, recovery keys or quorum cards, and when was recovery last tested?
Retirement	How are keys destroyed, how is the device sanitized, and how is disposal documented?

For media sanitization, follow NIST SP 800-88 (clear, purge, destroy) or your national equivalent, and match the method to the media: overwriting works for hard drives but is unreliable for SSDs, where cryptographic erase or physical destruction is preferred. For HSMs and smart cards, use the vendor's zeroization procedure and record it.

Step 6: score the shortlist

A simple weighted matrix keeps decisions consistent and auditable:

Criterion	Weight	Device A	Device B
Meets threat model requirements	30%
Required certification, active and matching version	20%
Standards support and interoperability	15%
Firmware and vulnerability management	15%
Management, logging and scale	10%
Lifecycle, support window, total cost of ownership	10%

Adjust the weights to your context: a regulated payment environment weights certification higher; a research lab weights interoperability and tool support higher.

A one-page summary

Threat model first, then certifications that match it, then design questions.
Certificates are specific: model, firmware, configuration, status.
Buy from authorized channels, verify genuineness, initialize yourself.
Budget for spares, backups and recovery from the start.
Plan secure retirement before the first device is deployed.

Hardware is often the strongest link in a security design. These steps make sure it stays that way from purchase order to disposal.