Contributed article
Stefan Deiss
CEO and Co-Founder, The Hashgraph Group
Nobody responsible for enterprise security wants another database full of credentials. Yet that is still how much of digital identity works. Access rights, recovery details, personal information and service accounts are gathered into central systems for easier administration. It also gives an attacker one place to look.
The consequences have grown as those systems have taken on more. They now support employees, contractors, cloud applications, devices, APIs and automated agents. Compromise the identity layer and the attacker may gain a route into several applications. Verizon’s latest Data Breach Investigations Report recorded credential abuse at some point in 39% of breaches, even where it was not the initial route in.
There is another way to run identity. Let the credential live with the person or machine it belongs to. The organisation then verifies it when access is requested, instead of holding a copy for an attacker to find.
The blast radius is built in
Centralised identity systems solved a real problem. Organisations needed a reliable way to create accounts, assign permissions and remove access when someone left. A single directory made that job manageable.
It also meant that more systems depended on the same source of trust. An application does not need to be breached directly if an attacker can take over the identity that grants access to it. Unlike the theft of an ordinary database, the stolen information can be used to open other doors.
Encryption, stronger authentication and monitoring still matter, but they do not change the underlying design. Any alternative is only worth adopting if it reduces the damage a single compromise can cause.
Where the trust sits
A distributed ledger provides the shared record used to check the credential. A trusted issuer creates it, and it stays with the person or machine it relates to. When access is requested, the organisation checks the cryptographic proof against the ledger. The personal information itself stays off the ledger – distributed ledger technology changes where the trust sits, not where the data does.
The ledger’s role is narrower than people assume. It acts as a shared registry for checking an issuer’s verification keys and whether a credential has been revoked. The cryptographic proof itself shows where the credential came from and that it has not been altered.
Take a contractor who needs access to a regulated system. The organisation may need proof of security clearance, employment status or a professional licence. It does not need every document behind those claims, only confirmation that the credential came from a source it accepts. Each new relationship then adds less copied, stored information to protect.
Who gave the machine permission?
Machine access is easy to create and surprisingly easy to forget. An API key set up for one project can still be working years later, even after the people who requested it have moved on. AI agents make that harder to manage because they can use several systems and take actions without asking for approval each time.
That leaves security teams with some basic questions that are often hard to answer. Who authorised this identity? Which systems can it reach? When should that access end?
Verifiable credentials can attach those answers to the machine itself. Each time it requests access, the organisation can check where its authority came from and which limits were placed on it.
An AI agent might read email, approve a supplier request and access customer or payment data in the same workflow. Its authority can stretch across parts of the business that were previously handled by different people and systems.
The decision still belongs to the organisation
Cryptography gives the verifier something solid to check: who issued the credential and whether it has changed. The organisation decides whether that credential should be issued and what access it carries.
Security teams still make the judgement calls about who gets in and for how long. What changes is the quality of evidence available when they enforce them.
Authentication, revocation and monitoring still sit around that process. They can, however, stop copying the same sensitive identity information into every system that needs to trust it.
Security leaders should start by looking at where identity data is duplicated, which databases would create the widest impact if breached and which checks could use a verifiable credential instead.
For years, the answer to identity risk has been to build higher walls around the database. The better answer is to give attackers less worth finding inside it.
