A July 30, 2026 security advisory from hardware-wallet maker Coinkite exposed a failure pattern that also deserves attention in health information systems: a security-sensitive random value can have the right format while lacking the expected unpredictability. Coinkite said corrected firmware protects future seed generation but cannot change or repair seeds created by affected firmware.

The incident does not establish that hospital systems contain the same defect. It shows why teams cannot treat a successful function call as proof that a pseudonym, research identifier or authorization secret came from the intended random-number generator. The technical root cause and affected Coldcard releases are covered in APPI News' analysis of the firmware failure.

Valid output can conceal a security failure

Ordinary functional tests confirm that an identifier has the required length, an authorization request completes or a token can be redeemed. Those checks do not measure how difficult the value is to predict. A weak generator can therefore supply syntactically valid output while reducing the number of possibilities an attacker must examine.

The damage may also survive the software fix. New code can change the generator used from that point forward, but it does not retroactively change pseudonyms already distributed in research datasets or secrets used in completed authorization flows. Incident response must identify which outputs were created by the affected path, where they traveled and whether they can be replaced or revoked.

Checkpoint one: pseudonyms are only one part of de-identification

Pseudonymization replaces a direct identifier with another value so records can be linked without displaying the person's name or other direct identifier. If a system relies on that replacement value being hard to guess, a predictable generator weakens the control and may make linkage attacks easier. The actual exposure depends on the generator, the mapping table, other fields in the dataset and who can obtain the records.

Random identifiers are not a complete de-identification method. The US National Institute of Standards and Technology's SP 800-188 says that tools which merely mask personal information may not provide sufficient de-identification, and recommends measurable performance standards and re-identification studies. A review should therefore test the dataset's disclosure risk as well as the code that creates its pseudonyms.

This distinction prevents two opposite errors. A team should not assume that a random-looking subject ID makes a dataset safe, but it should not claim that one weak identifier automatically reveals every person either. De-identification remains a governed process involving data transformation, access conditions and an explicit assessment of re-identification risk.

Checkpoint two: SMART authorization depends on a secret verifier

Fast Healthcare Interoperability Resources (FHIR) is HL7 International's standard for exchanging health information. SMART App Launch adds an OAuth 2.0 authorization framework that allows apps to request defined access to FHIR data. Version 2.2.0 requires all SMART apps to support Proof Key for Code Exchange (PKCE), while SMART servers must support the S256 challenge method and must not support the plain method.

For each authorization request, the app creates a secret code_verifier and sends a SHA-256-derived code_challenge. It later presents the original verifier when exchanging the authorization code for an access token. IETF RFC 7636 defines the verifier as a high-entropy cryptographic random string, recommends generating a 32-octet random sequence and states that an intercepted authorization code cannot be redeemed without the verifier.

Diagram showing a SMART on FHIR app creating a code verifier, deriving a code challenge and exchanging an authorization code for an access token

A low-entropy verifier can narrow the guesses available to an attacker under the attack conditions described by the RFC. The protocol can still appear to work because the server checks whether the submitted verifier matches the earlier challenge, not whether the app's generator had the expected entropy. That conclusion is an engineering inference from the protocol, not a report of a verified breach in a SMART deployment.

Checkpoint three: test the source, path and finished build

Randomness assurance has several separate parts. An entropy source needs tests that can detect failures in its underlying noise process, while the application needs integration tests proving that the production call reaches the approved random-bit generator. Release review must also cover build flags, linked components and fallback behavior because source code can contain the right implementation without selecting it in the finished artifact.

NIST SP 800-90B specifies design and validation requirements for entropy sources and requires both startup and continuous health tests. Startup tests examine the noise source before output is released. Continuous tests look for failures while the source operates, although the standard cautions that resource limits mean such tests are generally aimed at gross failures rather than every possible weakness.

Those health tests do not replace build and integration checks. A practical review should fail closed when the intended cryptographic generator is unavailable, identify which implementation serves security-sensitive calls and exercise that path in the production configuration. This three-part structure is a system-design inference from the NIST requirements and the Coldcard failure, not a claim that SP 800-90B prescribes a health-sector checklist.

Past outputs need their own incident scope

When a random-number defect is confirmed, replacing the generator addresses only new output. Teams must separately inventory pseudonyms, research subject IDs, client secrets, reset links, nonces and other values created during the affected period. Each type of output has a different response: some can be rotated or revoked, while distributed research identifiers may require notification, access review or a new data release.

The priority is evidence about the deployed path. Statistical analysis of samples can reveal some failures, but clean-looking samples cannot prove that an attacker lacks a predictor or that the application called the intended implementation. Configuration review, dependency tracing, runtime health signals and records showing when each output was generated provide different pieces of the incident timeline.

Diagram of three random-number assurance layers: entropy-source health tests, production-path integration tests and build configuration review

Frequently asked questions

Does a weak random number generator make every de-identified dataset identifiable?
No. It can weaken a pseudonym that depends on unpredictability, but re-identification risk also depends on the remaining fields, the linking key, access controls and the data-release model.

Why can PKCE still complete when its verifier is weak?
The server verifies the mathematical relationship between the verifier and challenge. It does not measure how the client generated the verifier, so a predictable value can pass the protocol's normal equality check.

Can output statistics prove that a generator is secure?
No. Statistical and health tests can detect defined failure patterns, but assurance also depends on the entropy-source design, its validation and proof that the deployed application uses the intended generator.

What should a system owner check first?
Identify every security-sensitive value produced by randomness, trace each production call to its generator, review fallback behavior and determine whether past outputs can be rotated, revoked or reissued.