6 min read
Most organisations approaching eIDAS 2.0 begin with a compliance checklist. They map requirements, assign workstreams, prepare documentation and track implementation milestones.
That work is necessary, but it is not sufficient.
For banks, payment service providers, qualified trust service providers and regulated relying parties, eIDAS 2.0 is also a cryptographic infrastructure challenge. It affects signing architecture, key management, remote Qualified Signature Creation Device (QSCD) design, audit evidence, authentication flows, wallet integration and long-term algorithm agility.
Many organisations will not struggle because they misunderstood the regulation. They will struggle because their infrastructure cannot support the commitments their compliance programme has made.
The revised eIDAS framework establishes the legal foundation for the European Digital Identity Wallet and expands the role of trust services across Europe. The direction is clear: interoperable digital identity wallets, wider adoption of qualified electronic signatures and broader use of verifiable digital attestations.
But implementation is not only a legal exercise. eIDAS 2.0 affects the systems that create, protect, validate and evidence trust. These systems cannot be redesigned quickly at the end of a compliance programme. If audit evidence was not captured at the point of signing, it may not be possible to recreate it later. If key management architecture does not support the required qualified service model, documentation alone will not solve the problem.
The key question is no longer only: “Have we mapped the requirements?” It is also: “Can our infrastructure prove those requirements are being met?”
Mistake 1: Treating eIDAS 2.0 As A Compliance-Only Project
One of the most common mistakes is assigning eIDAS 2.0 primarily to legal or compliance teams, while security, cryptography and engineering teams are involved later.
This creates a risky sequence. Compliance teams define scope and timelines before validating whether the existing infrastructure can support those commitments. In many cases, it cannot.
A compliance commitment may require the organisation to prove how signing keys are generated and protected, whether signature creation data is managed within a compliant QSCD model, how remote signing is authorised, what evidence exists for each signing event and whether the architecture can satisfy applicable regulatory, audit or conformity assessment requirements.
These are not issues that can be resolved through policy alone.
When cryptographic infrastructure is retrofitted late in the process, the result is often expensive and fragile. Audit trails may lack cryptographic context, algorithm choices may be hard-coded into applications and key lifecycle events may not be linked to signing activity.
The better approach is to involve security, cryptography and architecture teams from the start. Compliance commitments should be validated against the organisation’s actual infrastructure before they become programme assumptions.
Mistake 2: Hard-Coding Cryptographic Decisions
The second mistake is designing eIDAS 2.0 infrastructure as if the technical environment will remain static. It will not.
The framework continues to evolve through implementing acts, certification schemes and technical guidance. At the same time, organisations are preparing for post-quantum migration and increasing demands for crypto-agility. This does not mean organisations should delay implementation. It means they should design for change.
Hard-coded cryptographic choices create long-term operational risk. This includes algorithms, key lengths, certificate policies, signature formats, timestamping rules and trust anchor configurations.
When requirements change, every hard-coded dependency becomes a development project. In regulated environments, changes may also trigger documentation updates, reassessment and regression testing.
eIDAS 2.0 infrastructure should therefore be designed with cryptographic agility in mind. Algorithms, policies and parameters should be configurable through governed processes rather than emergency code changes.
This is one reason many organisations are adopting centralised signing architectures, where cryptographic policies can be managed consistently across services rather than embedded in individual applications.
While eIDAS 2.0 does not currently mandate post-quantum cryptography, organisations should consider crypto-agility to accommodate future regulatory and cryptographic developments.
A signing service deployed today should not require major re-engineering every time cryptographic policy changes.
Mistake 3: Understanding Audit and Evidence Requirements
Another common mistake is assuming operational logging is the same as regulatory evidence.
Operational logs are designed for monitoring and troubleshooting. They are often rotated, compressed or retained only for limited periods. They may show that a system functioned, but not that a qualified signing operation occurred under the correct controls.
eIDAS 2.0 requires a different standard of evidence. For qualified signing environments, organisations may need to demonstrate:
- What was signed
- When the event occurred
- Which certificate and key were used
- Which algorithm and policy applied
- How the signer was authenticated
- How the signing action was authorised
- Whether a trusted timestamp was applied
- Whether the audit record is tamper-evident
These controls must be designed into the architecture from the beginning. They cannot reliably be reconstructed later.
In practice, this often requires a signing platform that can associate signing events, authentication context, certificate information and trusted timestamps within a single evidentiary framework.
Organisations that underestimate evidence requirements often discover gaps late in the process, when remediation is costly. Logs may lack cryptographic context, long-term reconstruction may be impossible and key lifecycle events may not be linked to signing activity.
Mistake 4: Assuming PSD2 and eIDAS 2.0 Are Automatically Aligned
This issue is particularly important for banks and payment service providers. eIDAS 2.0 and PSD2 are becoming increasingly connected through digital identity and wallet-based authentication. However, they are not the same framework, and compliance with one does not automatically satisfy the other.
The EUDI Wallet is expected to become part of the authentication landscape for regulated digital services, including financial services. Under eIDAS 2.0, certain relying parties will be required to accept the EUDI Wallet for specific identification and authentication scenarios, subject to the applicable implementing acts and regulatory obligations.
At the same time, PSD2 Strong Customer Authentication (SCA) continues to operate under its own legal and technical requirements. SCA is not simply two-factor authentication. It includes requirements around authentication elements, independence, dynamic linking and protection of personalised security credentials.
This creates important design questions for payment service providers. When a customer uses an EUDI Wallet during a payment journey, is the wallet:
- Identifying the customer?
- Authenticating the customer?
- Authorising the payment?
- Providing an attestation within the SCA process?
- Acting as one factor within a broader authentication flow?
These distinctions matter because they affect compliance, liability, fraud evidence and customer experience.
A wallet-based authentication event may support a payment flow without satisfying every PSD2 SCA requirement on its own. Organisations therefore need to map wallet journeys directly against PSD2 requirements instead of assuming eIDAS 2.0 acceptance automatically equals PSD2 compliance.
Mistake 5: Treating Key Management As A Backend Detail
One of the most serious mistakes is designing signing workflows before designing key management. Key management is the foundation of qualified signing infrastructure. Every other control depends on it.
Modern remote signing architectures increasingly separate business applications from signing and key management functions, allowing cryptographic controls to be governed centrally while maintaining a consistent user experience.
If signing keys are generated incorrectly, protected inadequately or activated under weak controls, the signing service is weakened regardless of how polished the user experience appears.
For qualified electronic signatures, signature creation data must be generated, managed and protected in accordance with QSCD requirements, including certified remote QSCD environments where applicable.
This creates architectural requirements around:
- Key generation and activation
- HSM and QSCD integration
- Remote signing authorisation
- Backup and recovery
- Key rotation and revocation
- Privileged access controls
- Separation of duties
- Key ceremony evidence
- Incident response
These controls cannot be treated as implementation details.
The wrong sequence is common: organisations design the customer journey first, build integrations and only later ask whether the key management architecture supports the required qualified service model. By that stage, remediation may require changes to operations, audit evidence, certification scope and user experience.
Key management should therefore be designed before signing workflows are finalised, with involvement from cryptography specialists, PKI teams, security architects and compliance stakeholders.
Mistake 6: Assuming Standard Security Testing Is Enough
Traditional security testing remains essential, but it does not automatically prove eIDAS 2.0 readiness. Penetration testing, vulnerability scanning and application security reviews typically focus on conventional risks such as exploitable vulnerabilities, weak access controls and insecure APIs.
eIDAS 2.0 also requires assurance at the cryptographic and trust-service layer. A signing service can pass a standard penetration test and still be poorly prepared for conformity assessment.
The key question is not only whether an attacker can exploit the application. It is whether the organisation can prove that its signing infrastructure, key management environment and operational controls satisfy the applicable trust-service requirements.
Trust-service assurance is not solely a cybersecurity exercise. It also requires demonstrable control over cryptographic operations, key lifecycles, signing authorisation processes and evidentiary records.
Security testing for eIDAS 2.0 should therefore extend beyond conventional application testing. It should include validation of HSM and QSCD integration, privileged access paths, audit trail integrity, key activation processes and evidence production.
What This Means In Practice
Many of the challenges described above ultimately come down to one question: how do organisations operationalise trust at scale?
For organisations implementing qualified electronic signatures, remote signing services or digital identity ecosystems, success depends on more than meeting regulatory requirements. It requires infrastructure that can securely manage signing keys, enforce signing policies, support remote QSCD models, produce auditable evidence and adapt to changing cryptographic requirements.
This is why many organisations are moving towards dedicated signing platforms that provide centralised control over signing operations, key management integration, auditability and crypto-agility. Rather than embedding signing logic directly into business applications, a dedicated trust infrastructure approach helps organisations maintain consistency across multiple use cases while simplifying governance and compliance.
Cryptomathic Signer is designed around these principles, enabling organisations to build secure remote signing services, integrate with HSM and QSCD environments, support qualified trust service operations and maintain the evidentiary controls required for high-assurance digital transactions.
Conclusion
eIDAS 2.0 is not simply another compliance programme. It is a trust infrastructure programme.
While regulatory analysis and implementation planning remain essential, long-term success depends on whether the underlying cryptographic architecture can support the required level of trust, assurance and auditability. Organisations that focus solely on compliance requirements risk discovering late in the process that their signing infrastructure, key management controls or evidence capabilities cannot support the operating model they intend to certify or deploy.
The most resilient implementations are built on strong cryptographic foundations from the outset. That means designing for secure key management, remote signing, crypto-agility, evidentiary integrity and future regulatory evolution, rather than treating these as implementation details to be addressed later.
For banks, payment service providers, QTSPs and other organisations participating in the European digital identity ecosystem, readiness is not measured solely by documented compliance. It is measured by the ability to demonstrate that trust services, signing operations and authentication processes are secure, auditable and sustainable over time.
As eIDAS 2.0 and the European Digital Identity Wallet ecosystem continue to mature, organisations that invest early in robust cryptographic infrastructure will be better positioned to adapt to new requirements, support emerging trust-service models and maintain confidence in their digital trust operations.
Download the full guide, eIDAS 2.0: Six Remote Signing Infrastructure Mistakes to Avoid.
Practical guidance for banks, PSPs, QTSPs and regulated organisations preparing for the European Digital Identity Framework.