One framework, several layers
Regulation (EU) No 910/2014 created common rules for electronic identification and trust services. Regulation (EU) 2024/1183 amended it to establish the European Digital Identity Framework and extend the trust-service landscape. The consolidated text should be read together with applicable implementing acts and current standards.
The regulation defines legal categories and effects. Supervisory and conformity-assessment processes address provider and service status. Trusted lists publish authoritative status information. Standards then supply detailed policy, security, format, protocol and assessment requirements.
Electronic, advanced and qualified signatures
| Level | What it describes | Key point |
|---|---|---|
| Electronic signature | Data in electronic form used by a signatory to sign. | It cannot be denied legal effect or admissibility solely because it is electronic or not qualified. |
| Advanced electronic signature | A signature meeting the regulation’s requirements for linkage, identification, control and change detection. | The technical and procedural implementation must support all requirements. |
| Qualified electronic signature | An advanced signature created by a qualified creation device and based on a qualified certificate. | It has the equivalent legal effect of a handwritten signature across EU Member States. |
Electronic seals apply related concepts to legal persons. A seal can support origin and integrity, but it is not simply another name for an individual’s signature.
Services, providers and trusted status
eIDAS distinguishes a trust-service provider from each trust service it provides. Qualified status belongs to the specific service after the applicable assessment and supervisory process; it should not be inferred from branding, a certificate chain alone or the status of a different service from the same provider.
EU/EEA national trusted lists and the Commission’s List of Trusted Lists form the authoritative route for qualified status and status history. Validation therefore needs the relevant service identity and status at the time being assessed, not only the provider name as it appears today.
What implementation teams need to decide
- The exact service and jurisdiction in scope
- The legal category or qualified status being sought or relied upon
- The applicable implementing acts and standards versions
- Policy, identity, key-management and operational controls
- How trusted-list, certificate-status and time evidence will be obtained and retained
- How technical validation results map to business acceptance and risk
The framework continues to evolve. Projects should maintain a controlled regulatory and standards baseline rather than rely on an undated checklist.