Digital identity wallets make verified proof portable for runtime access

At a glance

What this is: Digital identity wallets move verified identity proof out of the issuer and into reusable, portable credentials that still require runtime authorization.

Why it matters: This matters because IAM teams must separate proof from permission across human, NHI, and agentic workflows instead of treating a credential as an access decision.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Curity's analysis of digital identity wallets and runtime authorization

Context

Digital identity wallets are changing where verified proof lives. Instead of keeping identity evidence trapped inside the organisation that performed the original check, wallets let a person present trusted claims again when another party needs them. For IAM teams, that shifts the centre of gravity from issuing identity proof once to evaluating how that proof should be trusted later.

The hard boundary is still authorization. A portable credential can show that a claim was verified, but it does not by itself decide whether a specific transaction should proceed. That distinction now matters for human users, service interactions, and AI agents, because the same proof may be reused across different contexts and risk levels.

Key questions

Q: How should security teams use digital identity wallets without weakening access control?

A: Treat wallet-presented credentials as trusted evidence, not as automatic authorization. The verifier should confirm issuer trust, integrity, and revocation status, then hand the claim to a policy engine that decides whether the requested action fits the current context and delegation boundary.

Q: Why do digital identity wallets matter for IAM programmes?

A: They make verified identity data portable, which means identity proof can be reused outside the original issuer. That improves portability, but it also forces IAM teams to separate identity verification from access approval so the same credential is not treated as universal permission.

Q: What should teams do when a valid credential is not enough for the action being requested?

A: Use step-up evidence at the transaction boundary. If the requested action is sensitive, the system should demand stronger proof such as additional wallet evidence or proof-of-possession before allowing the action to proceed.

Q: Who is accountable when portable identity proof is accepted too broadly?

A: The organisation operating the authorization decision is accountable, because the failure is usually in policy design rather than in credential format. Teams should document which claims are accepted, which actions they cover, and where extra evidence is mandatory.

Technical breakdown

Verifiable credentials as portable proof

A verifiable credential is a cryptographically protected statement about a subject, such as identity proofing, employment, or organisational membership. In a wallet model, the user stores that credential and presents it to a verifier without forcing the original issuer to be in the loop every time. The technical shift is portability, not blanket trust. The verifier still has to check authenticity, issuer trust, revocation status, and policy fit before treating the claim as usable evidence. That makes the credential an input to authorization, not a substitute for authorization.

Practical implication: Treat wallet-presented credentials as evidence that must be checked against policy, not as a direct access grant.

Why proof and authorization are different steps

Proof answers whether a claim can be trusted. Authorization answers whether that trusted claim should be sufficient for the requested action in this moment. Those are separate control points because access decisions depend on context, delegation, assurance, and transaction sensitivity. A wallet may present a valid credential, but the decision engine still needs to consider whether the requester is acting within the right authority boundary and whether additional evidence is required. This is why portable identity works only when runtime policy evaluation remains in place.

Practical implication: Keep policy evaluation downstream of credential verification so the access decision stays context-aware.

Just-in-time evidence for sensitive transactions

Just-in-time authorization extends the model by requesting stronger evidence only when a workflow reaches a higher-risk action. That could mean a wallet presentation, a client challenge, or proof-of-possession material tied to the current session. The point is to avoid forcing every interaction to carry the highest assurance burden, while still escalating evidence when the requested action changes. This becomes especially relevant when software acts for people or organisations and the authority question can change mid-flow.

Practical implication: Use step-up evidence only at transaction boundaries that genuinely require stronger assurance.

Threat narrative

Attacker objective: The objective is to turn portable proof into unauthorised access or overbroad authority at the moment of decision.

1. Entry begins when a verifier accepts a portable credential presented from a digital wallet as trusted identity evidence.
2. Escalation occurs if the authorization layer treats that proof as sufficient without checking delegated authority, context, or action sensitivity.
3. Impact follows when reused claims or weak runtime checks allow high-risk actions to proceed without the right assurance boundary.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Portable proof creates a governance gap whenever teams confuse verification with authorization. Wallets make verified claims easier to carry, but the governance problem shifts to deciding when a claim is strong enough for a specific action. That matters across human, NHI, and agentic workflows because the same credential can support very different authority decisions. The practitioner conclusion is simple: portable identity only works when the access decision remains separate from the proof.

Wallet-based identity is becoming an enterprise control surface, not just a user convenience feature. Once credentials can move across issuers and verifiers, identity governance has to account for trust reuse outside the original enterprise boundary. That broadens the need for policy, auditability, and revocation-aware handling of claims. The practitioner conclusion is that wallet acceptance becomes part of IAM design, not a frontend choice.

Verified claims only become operationally useful when the runtime layer can evaluate context and delegation. Curity's framing makes the real issue explicit: proof is portable, but authority is situational. That is especially relevant where users, business clients, and AI agents all present evidence differently. The practitioner conclusion is that access architecture must distinguish identity evidence from action approval.

Runtime trust will increasingly be the point of control for agentic and human workflows alike. As software acts with more delegated authority, the old assumption that identity proof happens once at login becomes weaker. The field needs to treat authorization as the living control plane for reused credentials, not as a backend afterthought. The practitioner conclusion is to build for evidence that changes with the transaction.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Lifecycle Processes for Managing NHIs becomes more relevant when portable credentials must still be provisioned, reviewed, and revoked with precision.
• 52 NHI Breaches Analysis shows how reusable credentials can become a long-lived exposure path when governance does not keep up.

What this signals

Portable credentials will push IAM teams to treat authorization as the primary control plane. The practical issue is no longer whether a claim can travel, but whether the organisation can make a consistent decision every time that claim is reused. That means policy design, audit trails, and revocation handling need to be built for reuse, not just issuance.

Verified proof will increasingly flow across human and machine workflows. The same portability that helps a person reuse a credential also creates new pressure on workload and agent governance, because delegated authority can outlive the original assurance moment. Teams should expect more demand for transaction-scoped evidence rather than broad session trust.

Only 5.7% of organisations have full visibility into their service accounts, so reuse risks are already hard to govern in machine identity programmes. As wallet-based proof expands the number of places where trusted claims can be accepted, the identity boundary gets wider, not simpler. The right response is to tighten decision points before portability outpaces governance.

For practitioners

• Separate verification from authorization Design wallet acceptance so the verifier checks credential authenticity and issuer trust first, then passes only validated claims into the authorization engine for context-based decisions.
• Define transaction-level evidence thresholds Map sensitive actions to the extra evidence they require, such as proof-of-possession or a wallet presentation, instead of using a single assurance level for every request.
• Review delegated authority paths Trace where humans, apps, and AI agents can reuse the same claim across workflows, then identify where the authority boundary should be rechecked before the action completes.
• Add revocation-aware claim handling Make sure wallet-presented credentials are checked against revocation and freshness rules before they are accepted in downstream policy decisions.

Key takeaways

• Digital identity wallets make verified proof portable, but they do not remove the need for runtime authorization.
• IAM teams must stop treating a valid credential as equivalent to a valid access decision across human, NHI, and agentic workflows.
• The control question is no longer who issued the proof, but where that proof is allowed to drive an action.

Key terms

• Verifiable Credential: A verifiable credential is a digitally signed statement that lets a holder prove a claim about identity, status, or authority. The important property is that the claim can be checked by a verifier without needing the original issuer to reissue the proof for every transaction.
• Digital Identity Wallet: A digital identity wallet is software that stores and presents credentials for a person or organisation. It is a portability layer, not an authorization system. The wallet moves verified proof between parties, while the relying party still has to decide whether the proof is sufficient for the requested action.
• Just-in-time Authorization: Just-in-time authorization is a decision pattern that asks for stronger proof only when the current transaction requires it. Instead of granting the same assurance for every request, the system escalates evidence based on context, risk, and delegated authority, which is especially useful in mixed human and machine workflows.
• Runtime Authorization: Runtime authorization is the live evaluation of policy, context, and evidence at the moment an action is requested. It differs from one-time login checks because the system can still reject or strengthen access when the risk, actor, or requested operation changes after initial authentication.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Curity: Digital identity wallets and runtime authorization decisions. Read the original.