How should organisations evaluate blockchain-based identity systems that combine public and permissioned ledgers?

Organisations should assess whether the design separates sensitive identity data from public verification data, reduces trust in a single operator, and preserves user control. The key question is not whether blockchain is used, but whether the architecture improves integrity, availability, and selective disclosure without creating unnecessary complexity, latency, or recovery risk in identity workflows.

Why This Matters for Security Teams

Blockchain-based identity systems are often evaluated as if the ledger itself is the security control. That is the wrong lens. For identity workflows, the real test is whether the architecture improves integrity, availability, auditability, and selective disclosure without leaking sensitive identity data into places that are hard to revoke or recover. NHI Management Group notes that Ultimate Guide to NHIs reports 68% of organisations do not know how to fully address NHI risks, which is a useful warning sign for any new identity pattern that adds complexity before it adds control.

The combination of public and permissioned ledgers can help separate public verification from controlled administration, but it can also create false confidence if teams assume immutability equals trust. A public chain may preserve proofs, while a permissioned layer still concentrates governance, key management, validator trust, and recovery duties. Security teams should evaluate who can write, who can revoke, who can correlate identities across ledgers, and how quickly a bad binding can be corrected. The right answer is not “blockchain yes” or “blockchain no,” but whether the design measurably reduces operator dependence and data exposure. In practice, many security teams discover these weaknesses only after identity recovery or revocation has already failed.

How It Works in Practice

The strongest designs usually split identity functions across layers. A permissioned ledger may manage enrolment, governance, and controlled credential issuance, while a public ledger stores only non-sensitive verification artifacts such as hashes, attestations, or revocation proofs. That separation matters because identity data on an immutable public chain is difficult to retract, and identity systems need revocation, recovery, and exception handling as normal operations, not edge cases. Current guidance suggests treating the ledger as an integrity substrate, not as a replacement for authentication, authorisation, or lifecycle management.

Practitioners should test the design against five questions:

• What personal or operational identity data is written publicly, and can it be linked back to a real subject?
• Who operates the permissioned validators, and what happens if one administrator is compromised?
• How are keys issued, rotated, and revoked when a wallet or signing service is lost?
• Can selective disclosure be enforced so only the minimum necessary claims are revealed?
• Does the recovery path preserve business continuity without reintroducing a central trust bottleneck?

For baseline identity controls, the structure should still align with traditional guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls and the threat patterns called out in OWASP Non-Human Identity Top 10, especially around secret handling, revocation, and over-privileged service access. The architecture should also be judged against NHI failure modes documented in 52 NHI Breaches Analysis, because the same operational failures that affect service accounts often surface in ledger-backed identity tooling. These controls tend to break down when multiple organisations share governance but not incident response authority, because revocation and recovery become slower than the attack window.

Common Variations and Edge Cases

Tighter privacy controls often increase operational overhead, requiring organisations to balance selective disclosure against recovery speed, interoperability, and validator governance. That tradeoff becomes sharper when public and permissioned components are run by different entities, because no universal standard defines how much trust should sit in each layer.

One common variation is using the public ledger only for anchoring proofs while the permissioned network handles issuance and status checks. That can be reasonable, but it still leaves questions about validator collusion, data retention, and whether the permissioned layer becomes a hidden single point of failure. Another edge case is cross-border identity exchange, where jurisdictional rules may prevent even hashed data from being treated as non-sensitive. In those cases, the best practice is evolving toward data minimisation, strong cryptographic proofs, and explicit retention rules rather than maximal on-chain transparency.

Organisations should be especially cautious with wallets, recovery agents, and delegated administration. If the recovery model depends on a human help desk or a central operator, the design may simply relocate the trust problem instead of solving it. The most resilient systems publish only what must be verifiable, keep revocation simple, and ensure the permissioned layer can fail without corrupting the public record. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference for spotting where identity control degrades once operational reality meets design assumptions.

Related resources from NHI Mgmt Group

• How should organisations evaluate whether blockchain node architecture is suitable for identity verification in decentralised applications?
• How should organisations evaluate blockchain-based identity systems for privacy and recovery risks?
• How should organisations design digital identity systems that minimise unnecessary data sharing during authentication?
• How should security teams evaluate blockchain as an alternative to centralized databases for protecting sensitive identity data?