What do security teams get wrong about privacy-preserving identity?

Why This Matters for Security Teams

Privacy-preserving identity is often marketed as a selective disclosure problem, but security teams usually feel the failure much earlier: during attribute issuance, trust establishment, and revocation. Once privacy is treated as an overlay, the identity stack tends to over-collect data, over-share claims, and create hidden correlation paths that undermine both minimisation and assurance. The result is a system that looks privacy-aware in policy documents but behaves like conventional identity in production.

This matters because identity controls are now part of broader security and privacy obligations, not separate tracks. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls treats privacy and security as intertwined control objectives, while the GDPR requires data minimisation and purpose limitation by design. For NHI-heavy environments, the operational lesson is the same: if the identity layer cannot constrain what is issued, how long it remains valid, and who can correlate it, the privacy model becomes fragile.

NHIMG research shows how often this becomes a governance blind spot. In the Ultimate Guide to NHIs, only 5.7% of organisations reported full visibility into service accounts, and 96% store secrets outside secrets managers in vulnerable locations. In practice, many security teams discover privacy leakage only after attributes, tokens, or secrets have already been exposed through routine integrations rather than through intentional design review.

How It Works in Practice

Privacy-preserving identity works when privacy constraints shape the architecture from the start. That means limiting attribute release to the minimum necessary, using pairwise or sector-specific identifiers where appropriate, and avoiding globally correlatable persistent identifiers unless there is a strong operational reason. It also means deciding early which party issues claims, which party verifies them, and which party must never see the underlying data.

For security teams, the practical question is not just “can the user prove who they are?” but “can they prove only what is needed, to only the intended verifier, for only as long as required?” Current guidance suggests that this is a control design problem, not a UI preference. The issuer, wallet, verifier, and revocation service all need privacy-aware trust boundaries. That includes logging and telemetry choices, because metadata can be more revealing than the assertion itself.

• Minimise attributes at issuance rather than filtering them later.
• Use short-lived proofs and explicit audience restrictions to reduce replay and correlation.
• Separate identity proof from data retrieval when possible, so verifiers do not become data collectors.
• Design revocation and expiry to work without exposing unnecessary personal or operational attributes.

Implementation teams often pair these controls with policy-based checks and selective disclosure standards, but there is no universal standard for this yet. The most defensible approach is to map privacy requirements to identity flows and test the data path end to end, not just the authentication event. NHIMG’s Top 10 NHI Issues is useful here because over-privilege and secret sprawl frequently expose more than the identity system intended. These controls tend to break down when legacy directories must remain authoritative, because persistent identifiers and broad attribute replication are difficult to unwind safely.

Common Variations and Edge Cases

Tighter privacy controls often increase operational overhead, requiring organisations to balance disclosure minimisation against auditability, fraud detection, and supportability. That tradeoff is real, especially where regulators, partners, or internal investigators need traceability. Best practice is evolving, and there is no universal standard for this yet across all identity models.

One common edge case is federation. If an enterprise depends on a third-party IdP, privacy-preserving design can fail when the upstream provider issues broad claims that downstream services keep forever. Another is analytics and incident response: teams may want richer identity telemetry, but collecting it by default can undermine the privacy posture they are trying to preserve. In those cases, use retention limits, scoped access, and explicit escalation paths rather than broad, permanent logging.

Another failure mode appears in non-human identity. Machine identities often need workload-specific claims, short TTLs, and constrained audiences, but teams still map them to human-style directories and static roles. That can unintentionally create more correlation than a privacy-preserving model should allow. The strongest practice is to treat identity as a data minimisation problem across issuance, transport, storage, and audit, not just as a login problem. In mature environments, the privacy design breaks down most often when integration teams copy claims into downstream systems for convenience, because that is where correlation becomes durable.

Related resources from NHI Mgmt Group

• What do security teams get wrong about marketplace identity verification?
• What do teams get wrong about building trust through digital identity?
• What do security teams get wrong about lateral movement prevention?
• What do security teams get wrong about machine-readable compliance data?