TL;DR: Digital identity has moved past proving who someone is and into orchestrating trusted interactions across issuers, sectors, borders, and delegated authority, according to Uniken, with EUDI Wallet acceptance becoming mandatory for some relying parties from December 2027. The governance problem is now evidence, policy, and trust travel, not basic credential verification.
At a glance
What this is: This is an analysis of how digital identity is shifting from identity proofing to orchestrating trusted interactions across institutions, borders, and delegated authority.
Why it matters: It matters because IAM, IGA, and identity architecture teams need to treat credential acceptance, trust evidence, and delegation as governance problems, not just integration tasks.
By the numbers:
- From December 2027, organisations already required to use strong customer authentication must accept an EUDI Wallet credential when a customer chooses to present one.
👉 Read Uniken's analysis of digital identity trust orchestration and EUDI acceptance
Context
Digital identity is no longer mainly about proving that a person is who they claim to be. The harder problem is deciding what can be trusted about an interaction, including the credential, the issuer, the authority behind the presentation, and the conditions under which that trust is valid. For IAM and identity architecture teams, that changes the programme from authentication design to trust orchestration.
That shift also widens the governance surface across human identity, delegated authority, and AI-assisted interactions. When trust must travel across sectors and borders, the controls that matter are not just login success and verification strength, but evidence, policy binding, accountability, and interoperability. Teams that still frame this as a point integration problem will miss the lifecycle and assurance issues that now define the domain.
Key questions
Q: How should organisations govern credential acceptance in cross-border identity systems?
A: Treat credential acceptance as a governance decision, not an integration task. Define which issuers you trust, what evidence must accompany each presentation, how authority is proven, and what audit trail must survive across borders and sectors. Without those rules, the same credential can be technically valid yet operationally untrustworthy.
Q: Why does delegated authority create more risk than simple authentication?
A: Authentication proves a subject presented a valid credential. Delegated authority proves that the subject was allowed to act for someone else, in a specific context, at a specific moment. That extra layer is where policy can fail, especially when software intermediaries or AI agents act on behalf of humans without clear authority tracing.
Q: What breaks when identity proofing is weak?
A: Weak proofing lets the organisation issue credentials to the wrong person or entity, which means later access controls are protecting an assumption that was never verified. In practice, that leads to fraud risk, onboarding mistakes, and downstream trust problems that access reviews cannot fully repair. Proofing is the foundation, not an optional pre-step.
Q: How can security teams prepare for EUDI-style wallet acceptance requirements?
A: Start by reviewing relying-party policy, evidence retention, issuer trust criteria, and exception handling. Then test whether your architecture can accept a wallet credential while preserving the proof needed for audit and dispute resolution. If those capabilities are missing, the gap is governance, not just development effort.
Technical breakdown
Credential verification vs trust orchestration
Credential verification answers a narrow question: does this credential appear valid at the point of presentation? Trust orchestration is broader. It has to establish what the credential proves, who issued it, what authority the presenter has, and whether that claim remains valid across a transaction, sector boundary, or jurisdiction. This is why the article separates identity from trust conditions. The technical problem is not only cryptography, but state, evidence, and relying-party policy across multiple systems.
Practical implication: Treat acceptance logic, issuer trust, and presentation evidence as separate control layers in your IAM architecture.
Delegated authority and AI agent identity
Delegated authority becomes the thin part of the stack when a person acts through software or an AI agent. In that case, the question is not only who is authenticated, but who authorised the action and whether the relying party can prove that authority at the moment of interaction. That introduces identity chaining, consent scope, and context-bound authorisation. For autonomous or semi-autonomous actors, the assurance model must capture provenance and delegation state, not just the final authenticated subject.
Practical implication: Model delegated access as an auditable chain of authority, especially where software agents act on behalf of humans.
Cross-border identity, wallets, and regulatory evidence
Cross-border identity systems fail when every jurisdiction or sector treats trust as local and static. The article points to device binding, dynamic linking, wallet attestation, and combined presentation as elements of an evidence model, not merely authentication features. That matters because regulators care about what was bound to what, on whose authority, and whether that can be demonstrated after the fact. The result is a governance-heavy architecture where evidence continuity is as important as user experience.
Practical implication: Design trust frameworks that preserve evidence for audit, dispute handling, and cross-jurisdiction acceptance.
NHI Mgmt Group analysis
Trust orchestration is the real identity programme now. The industry has largely solved the mechanics of proving a credential, but not the governance of deciding when that credential can be trusted across organisations, sectors, and borders. That changes identity from a single authentication event into a policy and evidence problem. Practitioners should stop treating verification as the endpoint and start treating trust conditions as the control surface.
Delegated authority is where identity models become fragile. The article correctly identifies that the hardest open question is not who a subject is, but what they are authorised to do on someone else’s behalf. That problem expands sharply when AI agents or other software intermediaries enter the flow, because the relying party must prove authority at interaction time, not merely at enrolment. The implication is that identity governance must follow the delegation chain, not just the user.
Minimal disclosure is now a governance requirement, not a privacy preference. The post’s proof-of-age example shows that the most scalable reusable credentials are often the ones that reveal the least. That aligns with privacy by design and with least data principles in identity assurance programmes. The practical conclusion is that better trust systems will increasingly depend on narrower claims, stronger issuer accountability, and unlinkable presentation.
EUDI-style acceptance shifts the market from integration to obligation. Once acceptance becomes mandatory for some relying parties, the question changes from whether a system can support a wallet to whether the organisation can operationalise trust policy, auditability, and acceptance criteria. That is a governance problem with architecture consequences. Identity teams should reassess their roadmaps through a trust-orchestration lens, not a feature checklist.
Cross-border identity will expose weak lifecycle governance fast. Systems that cannot track issuer trust, revocation, authority changes, and reliance conditions will struggle when identity claims have to travel across legal and technical boundaries. The article’s emphasis on accountable change control and mutual recognition is a signal that identity lifecycle management now includes more than joiner-mover-leaver mechanics. Practitioners need durable evidence trails, not just successful logins.
From our research:
- The most developed and most widely deployed reusable credential with biometrics today is proof of age, not a national identity wallet, according to The State of Secrets in AppSec.
- From our research: Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to The State of Secrets in AppSec.
- The right next step is to connect credential acceptance with lifecycle governance, as outlined in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.
What this signals
Minimal disclosure is becoming the operating principle for durable trust. Once identity systems have to work across sectors and borders, the smallest claim that still satisfies the decision is usually the most governable claim. That is why acceptance policy, issuer trust, and evidence retention belong in the same design conversation, especially where digital identity and delegated access intersect.
Programme owners should expect the next wave of identity work to shift from onboarding throughput to trust portability. The practical question is whether your architecture can preserve a usable audit trail when a credential crosses legal domains, changes context, or is presented through a delegate. That is a governance test as much as a technical one.
The post also reinforces a broader NHI and IAM pattern: evidence must outlive the interaction. When the claim, the issuer, and the authority behind it cannot be reconstructed later, the identity control failed even if the login succeeded. Teams should align wallet acceptance, delegation review, and exception handling before rollout expands.
For practitioners
- Map trust conditions separately from authentication Document which parts of your identity stack prove identity, which parts prove issuer trust, and which parts prove delegated authority. Use that map to identify where a relying party is currently making assumptions without evidence.
- Design for evidence continuity across boundaries Make sure wallet acceptance, presentation, and transaction binding preserve enough context for audit, dispute handling, and regulatory review. If evidence cannot travel with the credential, trust cannot travel either.
- Model delegated authority as a lifecycle problem Track when authority is granted, changed, and revoked for humans, service accounts, and AI-assisted actors. If the delegation chain changes, the acceptance policy should change with it.
- Prioritise minimal disclosure where claims are sufficient Use the smallest credential or claim set that satisfies the relying party’s decision. That reduces stored data, narrows liability, and makes reusable identity schemes easier to govern at scale.
Key takeaways
- Digital identity is moving from proving who someone is to proving what can be trusted about an interaction.
- Delegated authority and cross-border acceptance are now the main governance gaps, not core credential verification.
- Identity teams should shift investment toward evidence, issuer trust, and lifecycle controls that survive jurisdictional boundaries.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and credential acceptance depend on access control and trust decisions. |
| Recommendation: Map wallet acceptance and delegation rules to PR.AC-1 and document who can rely on each credential. | ||
| NIST SP 800-63 | SP 800-63C | Federated trust and assertion handling are central to cross-border credential acceptance. |
| Recommendation: Use federation guidance to define issuer trust, assertion validity, and relying-party policy. | ||
| NIST Zero Trust (SP 800-207) | 4.1 | Zero Trust principles fit the article's emphasis on continuous verification and trust conditions. |
| Recommendation: Apply zero-trust assumptions to acceptance decisions, not just login events. | ||
| ISO/IEC 27001:2022 | A.5.15 | Access control policy is directly relevant to acceptance criteria and delegated authority. |
| Recommendation: Update access control policy to define evidence, issuer trust, and exception handling for external credentials. | ||
| GDPR | Art.25 | Minimal disclosure and unlinkability map to privacy by design where identity claims carry personal data. |
| Recommendation: Limit identity data collection and presentation to the minimum needed for the relying party's decision. | ||
Key terms
- Trust Orchestration: Trust orchestration is the automation of certificate, key, and secret lifecycle work across deployment pipelines and operational systems. It links issuance, renewal, verification, and rollback into one controlled flow so machine identities behave consistently at scale.
- Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.
- Minimal Disclosure: Minimal disclosure is a privacy principle that limits identity systems to the smallest set of attributes needed for a decision. It reduces unnecessary data collection, lowers abuse potential, and helps organisations align identity verification with purpose and regulatory constraints.
- Relying Party: A relying party is the application or service that consumes an authentication assertion or token and grants access based on the identity proof it receives. In federation designs, its configuration quality directly affects whether trust decisions remain consistent and secure.
What's in the full article
Uniken's full blog covers the operational detail this post intentionally leaves for the source:
- How the Geneva discussions map to payment authentication, device binding, and wallet attestation in practice.
- The policy questions behind cross-border acceptance and accountable change control that this post only outlines.
- Why proof of age emerged as the most scalable reusable credential and what that implies for rollout strategy.
- The article's view on cooperation across ministries, private relying parties, and standards bodies.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 5, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org