Should organisations use PBKDF2 when FIPS certification is required?

Why This Matters for Security Teams

PBKDF2 is not the strongest password derivation choice, but FIPS certification requirements often narrow the field to approved algorithms rather than the best modern design. That matters because compliance teams are usually deciding under audit pressure, not in a greenfield security program. The practical risk is treating “FIPS approved” as the same thing as “good enough for every use case,” when the real job is to document the control objective and the residual risk clearly.

For NHI-heavy environments, this distinction is especially important. Secrets, service account credentials, and API keys often live far longer than they should, and Ultimate Guide to NHIs — What are Non-Human Identities notes that 96% of organisations store secrets outside secrets managers in vulnerable locations. That is where the real exposure usually sits, not in the derivation function alone. Current guidance from NIST Cybersecurity Framework 2.0 is to align controls to risk outcomes, which is why PBKDF2 should be treated as a constrained implementation choice, not a security endorsement.

In practice, many security teams discover the weakness of “compliance-only cryptography” only after a credential handling failure has already occurred.

How It Works in Practice

If FIPS certification is mandatory, the usual path is PBKDF2 with HMAC-SHA-256, configured with an iteration count that is as high as operationally tolerable. The key point is that FIPS validation speaks to algorithm approval and module boundaries, while security engineering still has to decide whether the password or secret lifecycle is defensible. For NHI workloads, that lifecycle often includes rotation, offboarding, and the prevention of long-lived secrets in code or build systems.

In practice, teams should document three things: why a FIPS-approved KDF is required, why stronger non-FIPS options such as memory-hard functions are not available for that specific control boundary, and what compensating controls reduce the exposure. Those compensating controls usually include vaulting, short-lived credentials, and strict access policy. The Sisense breach is a useful reminder that weak secret handling, not just weak cryptography, is what turns routine credentials into incident material. That is consistent with the governance emphasis in NIST Cybersecurity Framework 2.0, which pushes teams to manage identity and access as a continuous control process.

• Use PBKDF2 only where a FIPS requirement truly applies to the affected system or module.
• Set iteration counts through performance testing, not arbitrary defaults.
• Prefer short-lived secrets and rotation over relying on a stronger KDF alone.
• Record the exception, the control boundary, and the compensating measures in risk governance.

These controls tend to break down in CI/CD pipelines and distributed service-to-service authentication because secrets are copied, cached, and reused faster than teams can revoke them.

Common Variations and Edge Cases

Tighter compliance controls often increase operational overhead, requiring organisations to balance auditability against developer velocity and secret sprawl. That tradeoff is real: a FIPS boundary may make PBKDF2 the only acceptable choice, but it does not remove the need for strong lifecycle management. Best practice is evolving, and there is no universal standard for every environment, especially where hybrid estates mix regulated workloads with modern cloud services.

One edge case is a mixed estate where only part of the stack is inside a FIPS boundary. In that situation, some teams can use stronger KDFs outside the boundary and PBKDF2 only for the constrained component, but the boundary must be explicit and documented. Another common mistake is assuming FIPS certification alone solves secret exposure in non-human identities. It does not. If service accounts or API keys are still overprivileged, long-lived, or widely shared, the cryptographic choice is only one small part of the risk picture. The broader governance lesson from the Ultimate Guide to NHIs — What are Non-Human Identities is that identity lifecycle, visibility, and rotation usually determine the outcome more than the KDF label.

Where possible, organisations should revisit whether the certification requirement is for the platform, the module, or the data path. That distinction often changes the answer.

Related resources from NHI Mgmt Group

• Should organisations use the same identity controls for patients and clinicians?
• How should healthcare organisations use facial biometrics without creating new privacy risk?
• How should organisations enforce AI policy compliance across employee and agent use?
• How should organisations audit AI use that happens outside approved tools?