Topic starter
14/07/2026 5:24 pm
TL;DR: A write-integrity failure in PIV support has been addressed in Nitrokey 3 firmware v1.8.1, according to Nitrokey, after CVE-2025-25201 was found in 1.8.0 and earlier test builds that could accept invalid admin authentication keys and allow overwrite of certificates and other PIV data objects under physical or connected-device control. The issue exposes a write-integrity failure, not a readout of protected private data.
Editorial analysis by NHI Mgmt Group, based on content published by Nitrokey: “Nitrokey 3 Firmware v1.8.1 Security Update”.
Key questions
Q: What breaks when PIV admin authentication accepts invalid keys?
A: The write-integrity boundary breaks.
Q: Why does this flaw matter if protected private data could not be read?
A: Because identity systems depend on both secrecy and state integrity.
Q: What signs should teams look for after a PIV write-integrity issue?
A: Look for unexpected certificate replacement, unexplained key regeneration, and devices that were used through hosts you do not fully trust.
Practitioner guidance
- Verify PIV firmware version and update immediately Confirm every Nitrokey 3 instance using PIV is on firmware v1.8.1 or later, and prioritise devices that ran 1.8.0 or earlier test builds with PIV enabled.
- Reconcile certificate state after the update Check whether any PIV certificates or generated keys changed unexpectedly, especially on devices that were physically accessible or used through untrusted hosts.
- Separate read assurance from write assurance Review controls so PIN-based read protection, admin write authentication and certificate lifecycle checks are assessed as distinct control points.
Bottom line: The flaw was a write-integrity failure in PIV admin authentication, not a private-key exposure incident.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/07/2026 5:27 pm
Write integrity is a separate trust domain from secret protection: This flaw shows why smartcard programmes cannot equate protected reads with overall identity safety. The PIN path still protected read operations, yet admin write validation was broken, which is enough to corrupt trust state. For identity teams, certificate authenticity and object ownership need their own control model, because a device can remain confidential while no longer being trustworthy.
A question worth separating out:
Q: What should administrators do when a hardware token has been physically exposed?
A: Treat the device as needing trust revalidation, not just a password or PIN change. Recheck the firmware version, inspect certificate state, and decide whether the token should be reissued based on whether the custody chain was intact.
👉 Read our full editorial: Nitrokey 3 PIV write integrity flaw shows smartcard trust limits