eIDAS 2.0 and the EU Digital Identity Wallet: What Atlassian Customers Need to Know

[#1]

Executive summary 

• A shift from login-based trust ("who are you?") to proof-based trust ("can you prove this claim?"). 

• It will likely be seen first in Jira Service Management handling supplier onboarding, contractor verification, and external approval chains.

• Not a Guard replacement: SSO, SCIM, and Atlassian Guard stay foundational. This sits above them, at decision time. 

• Timeline: by the end of 2026 countries in the EU are obliged to offer a digital wallet. Adoption first in public sector, healthcare, banking, telecom, energy, and procurement-heavy sectors.   

---

Most enterprise workflows rely on surprisingly fragile trust once you look closely. A supplier uploads a PDF and someone reviews it by hand. A contractor claims to represent a company. An approver clicks a transition in Jira. A Confluence signoff becomes audit evidence. An email address stands in for identity. In a lot of organizations, this is still how operational trust works. 

That gets harder to sustain as collaboration expands beyond internal employees. Jira Service Management portals now pull in vendors, partners, contractors, and customers. Case handling stretches across organizational boundaries, and the data a case depends on — registrations, certifications, authorizations — arrives as unstructured attachments that someone has to read, interpret, and re-enter. 

Put together, those trends raise a question that goes beyond authentication: how do collaborative systems verify the information a case depends on — automatically, securely, and inside the workflow itself? That question sits close to what Europe is building through eIDAS 2.0 and the European Digital Identity Wallet, and Atlassian customers in regulated or procurement-heavy environments may run into the implications whether they plan for them or not. 

Four terms, briefly 

• eIDAS 2.0: the 2024 revision of the EU regulation on electronic identification and trust services. It requires every member state to make a digital identity wallet available to citizens and businesses. 
• EUDI Wallet: the European Digital Identity Wallet: the app that holds credentials and presents them, with the holder’s consent, to whoever asks for them. 
• Verifiable credential: a set of claims signed cryptographically by the organization that issued it, so a recipient can check who issued it and whether it is still valid. 
• Claim: a single assertion inside a credential: this person may sign for this company; this certification is valid until March. 

---

 This is not really about another login method 

Discussions of the EUDI Wallet usually start with authentication. That framing misses the more important shift underneath it. The change isn’t that users authenticate differently. It’s that workflows themselves become able to request portable, machine-verifiable proof, and identity is only part of what they can ask for. Over time, a system might request proof of authority, of employment, of certification, of legal representation, or of regulatory standing, and receive it as structured, cryptographically signed data rather than a document to be reviewed. 

Historically, enterprise trust has been centralized: an identity provider authenticates the user at login, directories and group membership establish access rights, and downstream workflows inherit those permissions. The wallet model changes the shape of that interaction. Instead of relying only on organizational identity established at login, a workflow can evaluate verifiable claims presented during the interaction itself, as data that can be validated automatically, attached to the case, and reused downstream. That distinction matters more than it first appears, especially inside collaborative systems. 

Jira and Confluence already operate as trust systems 

Few organizations describe Jira or Confluence as trust infrastructure, but operationally that’s often what they are. A Jira approval can represent financial authorization. A Confluence acknowledgement becomes audit evidence. A JSM onboarding workflow can decide whether an outside organization gets access to regulated systems. These platforms sit squarely inside governance, procurement, and compliance processes. 

The problem is the trust primitives underneath. Once external participants are involved, email identity stands in for identity, uploaded documents stand in for proof, and manual review stands in for verification. Organizations compensate with process: human review fills the gaps; compliance teams validate documents by hand, and procurement leans on evidence scattered across systems. It works, but it adds friction and overhead as case handling crosses more organizational boundaries. 

That is where the wallet conversation becomes practical for Atlassian customers. The interesting move is not stronger login security; it’s the prospect of verification becoming an automated step in the workflow itself. 

The shift is from login-based trust to proof-based trust 

Traditional trust model (login-based)	Emerging trust model (proof-based)
Identity provider	Wallet ecosystem
Centralized authentication	Portable trust
Access control	Verifiable claims
Manual verification	Machine-verifiable evidence
Uploaded documents	Verifiable credentials
Data re-entered by hand	Structured data flowing into the case
"Who are you?"	"Can you prove this claim?"

Existing identity systems don’t disappear. Atlassian Guard, SSO, SCIM provisioning, and workforce identity platforms remain foundational. The change happens higher in the stack. Instead of relying solely on identity established at login, workflows can begin evaluating verifiable claims presented during the interaction itself. The question shifts from “Who are you?” to “Can you prove this claim in this context?” That matters most in external collaboration, regulated approvals, supplier onboarding, and cross-organizational case handling. 

JSM is where most organizations would meet this first 

Supplier onboarding is the obvious case. Today it’s a mix of uploaded registration documents, tax certificates, manual validation, compliance review, and email confirmation — fragmented across systems and dependent on human checks. Every handoff is a point where data is re-entered, re-interpreted, or lost. 

Now imagine that same supplier representative opening a JSM portal and presenting verifiable credentials straight from a business wallet. Each step changes: 

Supplier onboarding today	With verifiable credentials
A portal account backed by an email address	Legal authority to represent the company, presented as a signed credential
Registration documents uploaded as PDFs	Registration status confirmed against the issuing registry
Tax certificates and compliance attachments queued for review	Certifications checked automatically, including expiration and revocation
Validation waits for a human reviewer	Verification runs as an automated step
Case fields re-entered by hand from attachments	Verified attributes populate case fields directly
Audit evidence scattered across systems and email threads	Evidence attached to the request and carried through every later stage

The workflow starts evaluating proof rather than trusting uploaded artifacts, a materially different model for onboarding, approvals, and auditability. In Atlassian terms, that verification could become part of the workflow itself. Verified claims could satisfy workflow conditions, trigger Automation rules, influence approval routing, or prevent a transition when a required credential is missing, expired, or revoked. 

The same pattern fits contractor verification, regulated procurement, and external approval chains where an email and a PDF aren’t enough assurance. 

It also reaches into governance records. Policies are reviewed in Confluence, change approvals and risk signoffs happen in Jira, and those decisions become the historical trail. Yet the underlying evidence is often just a username, a timestamp, and a transition. 

Regulated sectors increasingly need to capture not only who approved something, but under what authority, with what certification, on behalf of which legal entity. An external contractor approving a regulated change is not the operational equivalent of an internal employee doing it, and a supplier representative authorizing procurement is not a generic portal account. 

Organizations already understand these distinctions; what they lack is infrastructure that lets the workflow verify and preserve them automatically, rather than patching the gap with policy and human process. 

For organizations using Atlassian Assets, some of that verified information could also become part of the operational model itself. Information about suppliers, organizations, certifications, or authorized representatives could be maintained as governed objects rather than revalidated independently in every request. 

Atlassian Guard solves a different problem 

Guard addresses foundational concerns around workforce identity and centralized access: managed accounts, SSO enforcement, SCIM provisioning and security policies. The wallet conversation runs adjacent to that. The question is no longer only whether a user can authenticate, but whether a workflow can verify the specific claims attached to a transaction or approval, and whether those claims remain valid at the moment the decision is made.  

The question shifts from “Who are you?” to “Can you prove this claim in this context?” 

That matters because collaboration now extends well past the workforce boundary to customers, suppliers, contractors, and temporary external actors — relationships traditional identity models were never designed to handle at scale. 

AI may accelerate the need 

Most enterprise AI discussions still assume authorization runs through usernames, permissions, and roles. But an AI agent participating in a workflow may need to verify not just who a user is, but whether they are legally authorized to approve a transaction. 

As AI takes a larger role in procurement, onboarding, governance reviews, and operational approvals, trusted contextual evidence becomes more important, not because AI changes identity, but because automation raises workflow velocity, scale, and complexity. The more decisions are automated, the more pressure lands on evidence the system itself can check.  

That distinction matters regardless of which AI capability is involved. Atlassian's Teamwork Graph helps AI systems understand relationships between people, projects, work, and knowledge. Verifiable credentials solve a different problem: they provide trustworthy evidence that a specific claim is valid when a workflow needs to make a decision. Whether the work is assisted by Rovo, Claude, or another AI system, the question is the same: can the workflow rely on the claim it has been given? 

An AI agent may need to verify not just who a user is, but whether they are legally authorized to approve a transaction. 

Expect uneven adoption 

Few Atlassian customers are asking for EUDI Wallet integrations today. Many are early in cloud governance maturity, standards are still evolving, interoperability is unsolved, and there’s a wide gap between regulatory infrastructure existing and workflows adapting to it. That transition could take years. 

Organizations spend significant effort today proving things that systems cannot easily verify. 

Some sectors will feel the pressure sooner. Public sector, healthcare, banking, telecom, energy, and procurement-heavy enterprises already live with cross-organizational case handling, delegated authority, and regulated approvals. For them, portable and verifiable trust becomes less theoretical and more useful as wallet adoption normalizes across European public and private initiatives. 

There is an economic case here, too. Organizations spend significant effort today proving things that systems cannot easily verify. As more of that proof becomes portable and machine-verifiable, some of that effort can shift from manual validation to productive work. 

The bigger question may not be identity at all 

The most interesting part of this has less to do with identity management than with how collaborative systems establish trustworthy evidence across organizational boundaries: evidence of authority, legitimacy, delegation, certification, compliance, and context, flowing as verifiable data through the systems where cases are handled. Jira, Confluence, and Jira Service Management already sit in the middle of those processes. 

So Atlassian customers may end up thinking less about authentication and more about how their collaborative systems establish trusted, verifiable information between people, organizations, automation, and workflows. The European Digital Wallet could matter not because anyone needs another login method, but because enterprise case handling increasingly needs better ways to evaluate authority, legitimacy, and evidence across organizational boundaries.  

As those claims become machine-verifiable, collaborative systems can begin acting on trusted information rather than simply recording it. If that shift happens, Jira, Confluence, and Jira Service Management won’t simply record decisions. They will increasingly participate in establishing the trust those decisions depend on. 

Further Reading

• European Commission — European Digital Identity (EUDI) Regulation, including economic benefits 

• Regulation (EU) No 910/2014 (eIDAS) 

• European Digital Identity Wallet Architecture and Reference Framework 

• W3C — Verifiable Credentials Data Model 

• NIST — Zero Trust Architecture (SP 800-207) 

• Atlassian Guard documentation 

• ENISA — European Union Agency for Cybersecurity 

[Dave Rosenlund _Trundl_]

Great article, @Steinar Line - Kantega SSO ‼️

The part that jumps out at me is how mundane some of these use cases are.

Supplier onboarding. Contractor access. Approvals. Certifications. None of that sounds particularly futuristic. Yet we still spend an enormous amount of time asking humans to look at documents and decide whether the claims in them can be trusted.

Making the proof machine-verifiable inside the workflow is the interesting shift. It’s less about reinventing identity and more about removing a lot of manual trust from everyday work.

And, like GDPR before it, this may be one of those European developments that organizations well beyond Europe eventually need to understand and plan for.

Full Disclosure: I am an advisor to Kantega SSO.

[Mia Tamm _Simpleasyty_]

Hey @Steinar Line - Kantega SSO the bit I’d watch is what happens after verification. A credential can be valid when an approval happens and expire or get revoked later.

For audit purposes you probably need to preserve what was verified, when, and against which issuer — not just whatever the current state happens to be.

[Steinar Line - Kantega SSO]

@Mia Tamm _Simpleasyty_ that's the right thing to watch, and it's a part I left underexplored.

Verification is a moment while audit is a timeline. If a workflow writes "verified" into a field, that field stops meaning anything fairly quickly. And there are really two separate questions hiding in there: 

• Was this approval legitimate when it was made?
• Is this supplier still qualified today?

These need different mechanisms, and treating them as one is where I'd expect implementations to go wrong first.

So the verification record needs to carry what you describe: the claims relied on, the issuer, the trust anchor and revocation state as they stood, and a trustworthy timestamp which is a rather different artefact from a checkbox.

Probably worth its own article. Thanks for the nudge.