Skip to main content
Identity Authority
Category: Governance & Compliance

eIDAS

Also known as: eIDAS, electronic IDentification, Authentication and trust Services, eIDAS Regulation, eIDAS 1.0
Simply put

eIDAS is a European Union regulation that sets common rules for electronic identification and trust services such as electronic signatures, seals, and timestamps. Its goal is to let people, businesses, and public bodies carry out secure electronic transactions across EU borders. By establishing a shared legal framework, it aims to make cross-border digital interactions more convenient and trustworthy.

Formal definition

eIDAS (electronic IDentification, Authentication and trust Services) is an EU regulation that establishes a legal framework for electronic identification schemes and trust services, including electronic signatures, electronic seals, timestamps, and related services, to enable secure cross-border transactions across the EU. The framework covers both electronic identity assurance used to identify and authenticate principals and the trust services that support the integrity and provenance of electronic transactions; the specifics of assurance levels, mutual recognition, and qualified versus non-qualified trust services depend on the regulation's provisions and implementing acts. The evidence references an original framework designated eIDAS 1.0, indicating that subsequent revisions exist, but details of later versions are out of scope of the sources provided here.

Why it matters

For organizations operating across EU member states, eIDAS provides a shared legal foundation that makes electronic identification and trust services, such as electronic signatures, seals, and timestamps, recognizable and enforceable across borders. Before a common framework, the legal standing of an electronic signature or an identity scheme could vary from one jurisdiction to another, creating friction for cross-border digital transactions. eIDAS is intended to reduce that friction by establishing common rules that let citizens, businesses, and public bodies transact electronically with greater confidence in the provenance and integrity of what they exchange.

For IAM and identity governance teams, eIDAS matters because it connects the domains of identity assurance (identifying and authenticating principals) and trust services (supporting the integrity and provenance of electronic transactions) under one regulatory umbrella. Organizations that must accept or issue electronic signatures, or that rely on recognized identity schemes for cross-border interactions, need to account for how eIDAS classifies and treats those services. The distinction between qualified and non-qualified trust services, and the specifics of assurance levels and mutual recognition, depend on the regulation's provisions and implementing acts rather than on any single vendor's interpretation.

The evidence references an original framework designated eIDAS 1.0, which indicates that the regulation has been subject to subsequent revision. Teams tracking compliance obligations should therefore treat the version and its later revisions as material: requirements, assurance definitions, and the scope of covered services can change across revisions, and the details of later versions are beyond the scope of the sources summarized here.

Who it's relevant to

Compliance officers and legal teams
Those responsible for regulatory obligations in EU markets need to understand how eIDAS governs electronic identification and trust services, including the distinction between qualified and non-qualified trust services. Because these distinctions depend on the regulation's provisions and implementing acts, compliance teams should map their electronic signature and identity practices to the applicable requirements and track revisions beyond eIDAS 1.0.
Identity architects and IAM engineers
Architects designing systems that must accept or rely on EU-recognized identity schemes need to account for how eIDAS treats identity assurance used to identify and authenticate principals. The specifics of assurance levels and mutual recognition depend on the regulation, so design decisions should reference the applicable provisions rather than assume uniform behavior across member states.
Public sector and cross-border service providers
Public bodies and organizations transacting across EU borders benefit from eIDAS because it aims to make cross-border electronic transactions more convenient and trustworthy for citizens, businesses, and public bodies. These teams should understand which of their electronic identification and trust-service interactions fall within the framework's scope.
Teams handling electronic signatures, seals, and timestamps
Groups implementing or validating electronic signatures, electronic seals, and timestamps need to know that eIDAS provides the legal framework these trust services operate under. Whether a given service qualifies as a qualified trust service, and the legal effect that follows, depends on the regulation's provisions rather than on the technical mechanism alone.

Inside eIDAS

Regulatory framework for electronic identification and trust services
eIDAS is a European Union regulation that establishes a common legal framework for electronic identification (eID) and trust services across EU member states, aiming to enable cross-border recognition of identity and trust mechanisms. Specific article numbers and adoption dates are not asserted here; consult the official regulation text for precise citations.
Electronic identification (eID) schemes
A component covering national eID schemes that member states may notify for mutual recognition, so that a user identified and authenticated under one member state's scheme can be recognized when accessing services in another. Note that eIDAS addresses identification and authentication assurance at a legal/framework level rather than mandating a specific authentication protocol.
Levels of assurance (LoA)
eID schemes are typically associated with assurance levels commonly referred to as low, substantial, and high, which characterize the confidence in the claimed identity based on the identification and authentication processes used. The exact criteria and mappings depend on the implementing acts and each scheme's configuration.
Trust services
A category covering services such as electronic signatures, electronic seals, timestamping, electronic registered delivery, and website authentication certificates. These are distinct from eID: they concern the integrity, origin, or timing of data and transactions rather than authenticating a human principal for access.
Qualified vs. non-qualified trust services
eIDAS distinguishes qualified trust services (provided by qualified trust service providers meeting stricter requirements and subject to supervision) from non-qualified ones. Qualified electronic signatures, for example, typically carry stronger legal effect. A signature being qualified concerns legal status and provider requirements, not the same thing as a token or document being encrypted.
Trusted lists and supervisory bodies
Member states maintain trusted lists of qualified trust service providers and their services, and designate supervisory bodies. These mechanisms support the verification of whether a given trust service is qualified.

Common questions

Answers to the questions practitioners most commonly ask about eIDAS.

Is eIDAS an authentication protocol like OpenID Connect or SAML?
No. eIDAS is an EU regulatory framework for electronic identification and trust services, not a technical authentication protocol. It defines legal requirements, assurance levels, and mutual recognition obligations rather than the wire-level mechanics of authenticating a principal. In practice, member state identification schemes implemented under eIDAS may rely on underlying protocols (such as SAML 2.0 in the original eIDAS interoperability profile), but eIDAS itself sits at the governance and trust layer above those protocols. Treat it as a framework that constrains and certifies identity systems rather than as something you would configure in place of an authentication standard.
Does eIDAS compliance automatically mean strong multi-factor authentication is in use?
Not necessarily. eIDAS defines three levels of assurance, low, substantial, and high, and the strength of authentication required depends on which level a given scheme targets. Higher assurance levels typically impose stronger requirements around credential binding and factor combinations, but eIDAS specifies assurance outcomes rather than mandating a specific factor mix (such as a particular MFA configuration) for every use case. The actual authentication factors, whether knowledge, possession, or inherence, depend on the notified scheme and its assurance level, so assurance level and specific factor implementation should be assessed separately.
How does a relying party in one member state consume an identity issued under another member state's eIDAS scheme?
Cross-border recognition depends on the scheme having been notified and on connecting through the eIDAS interoperability infrastructure, which historically relied on national eIDAS nodes that mediate between member states. Depending on the deployment and the profile in use, the relying party interacts with its national node, which handles the cross-border exchange and translation of identity assertions. The specific integration pattern, attribute set, and assurance level available will vary by member state scheme, so confirm the notified status and supported attributes for each scheme you intend to accept rather than assuming uniform behavior across all member states.
What should we consider when mapping eIDAS assurance levels to our internal access decisions?
Because eIDAS defines low, substantial, and high as distinct assurance levels, treat the incoming assurance level as an input to authorization rather than as an authentication result alone. In most deployments you would map each level to the sensitivity of the resources or transactions a principal may reach, keeping the identification and authentication step (establishing who the principal is at a given assurance level) separate from the authorization decision (what they may do). The precise mapping is a policy decision specific to your risk posture and is out of scope for eIDAS itself, which defines the levels but not your resource-to-level policy.
Where do the attributes provided under an eIDAS scheme fit relative to our directory and provisioning processes?
Attributes received during an eIDAS-mediated identification flow are typically consumed at authentication time and represent asserted identity data at a point in time. Whether and how you persist those attributes into an LDAP directory or provision an account (for example via SCIM) is a separate governance and lifecycle concern from the runtime assertion. Depending on your architecture, you may create or link a local identity on first use, but you should distinguish the runtime attribute assertion from ongoing identity administration, and confirm what minimum attribute set a given scheme guarantees before designing provisioning logic around it.
What should we account for when the eIDAS framework or its profiles are updated?
eIDAS has evolved over time, including work on updated frameworks and profiles, so implementations should not assume the interoperability profile or supported mechanisms are static. Because behavior varies by member state scheme, notified status, and the profile version in use, plan for versioning in your integration and verify current requirements against the applicable regulation and technical specifications rather than relying on a fixed prior implementation. Specific version numbers, dates, and mandated technical changes should be confirmed against authoritative sources, as those details are outside what can be asserted here.

Common misconceptions

eIDAS is itself an authentication protocol like SAML or OpenID Connect.
eIDAS is a legal and regulatory framework for electronic identification and trust services, not a wire protocol. It defines assurance levels, legal effects, and mutual-recognition obligations. Actual authentication and federation in deployments are carried out by underlying schemes and protocols; eIDAS does not replace SAML 2.0 or OpenID Connect.
eIDAS trust services and eID are the same thing.
They are separate categories. eID concerns identifying and authenticating a principal for cross-border access to services, while trust services (electronic signatures, seals, timestamps, registered delivery, website certificates) concern the integrity, origin, or timing of data and transactions. A term should be attributed to the correct category rather than blurring the two.
A qualified electronic signature under eIDAS means the signed content is encrypted and confidential.
Qualified status concerns the legal effect of the signature and the requirements placed on the qualified trust service provider. Signing establishes integrity and origin, not confidentiality; being signed is not the same as being encrypted. Confidentiality would require separate encryption measures.

Best practices

Treat eIDAS as a framework layer: map its assurance levels (typically low, substantial, high) to your application's required identity assurance, and implement the actual authentication and federation with an appropriate protocol profile rather than assuming eIDAS provides one.
Keep eID and trust services as distinct concerns in your architecture, applying identification and authentication controls to the eID side and integrity/origin controls to the trust-service side.
When relying on qualified trust services, verify provider status against the relevant member state's trusted list and confirm supervision, rather than assuming a provider is qualified.
Do not conflate signing with encryption: if confidentiality is required for signed documents or transactions, add encryption explicitly as a separate control.
Document the specific assurance level required per service and validate that recognized cross-border eID schemes meet or exceed it before granting access.
Consult the authoritative regulation text and current implementing acts for precise article numbers, dates, and criteria, since these details vary and should not be assumed from memory.
Application Security Isn’t Optional Anymore.