eIDAS 2.0: SIX REMOTE SIGNING INFRASTRUCTURE MISTAKES TO AVOID

SIX REMOTE SIGNING INFRASTRUCTURE MISTAKES

• MISTAKE 1: TREATING EIDAS 2.0 AS ACOMPLIANCE PROJECT

  The first mistake is organisational.

  Many eIDAS 2.0 programmes start in legal, regulatory affairs, or compliance. Those teams map the framework, track dates, identify affected services, and define workstreams. That work is necessary. The problem starts when cryptography, security architecture, engineering, operations, product, and signing-service teams are brought in after commitments have already been made.

  At that point, the programme may already assume that existing systems can support the chosen regulatory interpretation. In many cases, that assumption is too optimistic.

  A compliance plan may require the organisation to prove:

  – How signing credentials are created;

  – Where signing keys are generated and protected;

  – Whether signature creation data is controlled within the appropriate QSCD model;

  – How remote signing operations are authorised;

  – How signer authentication is performed;

  – What the signer saw before authorising the signature;

  – What evidence exists for each signing or sealing event;

  – Whether audit records are complete and protected against unauthorised change;

  – How wallet-based identity and authentication events map into existing flows;

  – How signing formats, algorithms, and policies can be changed;

  – Whether the architecture can satisfy supervisory, audit, or conformity assessment expectations.

  These are implementation and evidence questions, not policy questions.

  When remote signing infrastructure is retrofitted late, the result is usually more expensive and harder to defend. Audit trails may not contain the right signing context. Signing credential lifecycle records may not link cleanly to signature events. Authentication journeys may satisfy one requirement while leaving gaps under another. Signature formats or policies may be embedded in code. Security testing may not cover the remote signing and trust-service layer.

   

  The organisation may appear ready on paper while the signing infrastructure remains difficult to assess.

  READINESS QUESTIONS

  1) Are signing-service owners, cryptography, security architecture, engineering, operations, and compliance teams involved from the start?
  2) Have regulatory commitments been checked against current remote signing, signing credential, and evidence infrastructure?
  3) Has each eIDAS 2.0 obligation been mapped to a specific technical control?
  4) Can each control be evidenced for audit, supervision, or conformity assessment?
  5) Is ownership clear for remote signing infrastructure, signer authentication, wallet integration, and evidence production?

• MISTAKE 2: Hard-Coding Signing and Cryptographic Choices Too Early

  The second mistake is designing eIDAS 2.0 signing infrastructure as if the technical environment were static. It is not.

  The revised framework is being implemented through technical specifications, implementing acts, certification requirements, standards, and operational guidance. Many technical rules are already specified, but operational interpretation, assessment practice, certification expectations, and implementation guidance can still evolve. At the same time, the cryptographic environment is changing as organisations prepare for post-quantum migration and longer-term algorithm transition.

  This does not mean organisations should wait. It means they should design for controlled change.

  Hard-coded signing and cryptographic choices create long-term operational risk. This includes hard-coded:

  – signing algorithms;
  – key lengths;
  – signature formats;
  – AdES profiles;
  – certificate policies;
  – signature activation parameters;
  – protocol parameters;
  – timestamping policies;
  – validation rules;
  – trust anchors;
  – revocation checking rules;
  – policy identifiers.

  When one of these dependencies changes, the organisation may need more than a configuration update. It may need development work, regression testing, documentation updates, change approval, reassessment, and production rollout. In a qualified or regulated service environment, that change may also affect audit scope or certification planning.

  In signing infrastructure, agility is not only about future algorithms. It affects signature formats, certificate policies, validation rules, time stamping, long-term validation, and the ability to keep signed evidence trustworthy over time.

  A more resilient signing architecture allows algorithms, parameters, policies, formats, trust configurations, and validation rules to be governed centrally and changed through controlled configuration wherever possible. That does not remove the need for assessment, testing, or approval. It reduces the chance that every policy change becomes a major engineering project.

   

  This matters for three reasons. Implementing acts and technical specifications can evolve. ETSI, CEN, certification, and conformity assessment expectations may change over time. Post-quantum migration will require organisations to revisit cryptographic assumptions that were once considered stable.

  A remote signing service deployed for eIDAS 2.0 should not require major re-engineering every time signing policy changes.

  Readiness Questions

  1) Are algorithms, key lengths, signature formats, validation rules, and policy identifiers configurable?
  2) Can certificate and signing policies be updated without code changes?
  3) Is there a formal governance process for signing and cryptographic policy changes?
  4) Has the signing architecture been assessed for post-quantum migration impact?
  5) Would a signing policy change trigger service downtime, reassessment, or recertification?
  6) Are signing dependencies documented clearly enough for operations, audit, and engineering teams to manage them over time?

• Mistake 3: Underestimating Audit and Evidence Requirements

  The third mistake is assuming that operational logging is the same as regulatory evidence. It is not.

  Operational logs are designed for monitoring, troubleshooting, performance analysis, and incident response. They may show that a system was available or that a transaction occurred. But they do not necessarily prove that a qualified signing operation was performed under the right policy, with the right credential, in the right environment, by the right authorised signer, with the right evidence retained for later reconstruction.

  For remote signing, evidence is not limited to the final signature. It also includes the signing context: what the signer saw, how the signer was authenticated, how the signature was authorised, and which policy controlled the event.

  For eIDAS 2.0, remote signing services and qualified trust service environments need a higher standard of evidence. Organisations may need to demonstrate that relevant controls operated correctly and that signing or sealing events can be reconstructed and verified later. This evidence may be needed for conformity assessment, supervisory review, dispute resolution, incident investigation, internal audit, or legal proceedings.

  For a signing event, the evidence model may need to show:

  – What was signed;
  – What the signer saw;
  – When the event occurred;
  – Which certificate was used;
  – Which signing credential or key was used;
  – Which algorithm, format, and policy applied;
  – Where the signing key was protected;
  – How the signer was identified or authenticated;
  – How the signing operation was authorised;
  – Whether a trusted timestamp was applied;
  – Whether the signed document or object can be validated later;
  – Whether the audit record is complete and protected against unauthorised change;
  – Whether the event can be reconstructed after long retention periods;
  – How relevant signing credential lifecycle events relate to the signing event.

  These requirements need to be designed into the architecture. They cannot reliably be added after the fact.

  The risk is highest when different evidence fragments sit in different systems: application logs, IAM logs, HSM logs, signing-service logs, credential lifecycle records, certificate records, time stamping records, transaction systems, workflow systems, and document archives. Unless the evidence model is designed deliberately, those records may not align when the organisation needs to prove what happened.

   

  The goal should be a coherent signing evidence model, not a collection of disconnected logs.

  That does not mean every organisation needs the same evidence structure. It means the evidence required for the intended service model should be defined early, captured at the point of action, protected against unauthorised change, retained for the required period, and tested for reconstruction.

  Readiness Questions

  1) Does the audit trail capture signing context at the point of signing?
  2) Can the organisation prove what the signer saw and authorised?
  3) Are audit records complete, durable, and protected against unauthorised change?
  4) Can signing or sealing events be reconstructed after long retention periods?
  5) Are signing credential lifecycle events linked to signature evidence?
  6) Are authentication, authorisation, certificate, time stamping, and document records correlated?
  7) Has the evidence model been tested against audit, legal, and conformity assessment expectations?

• Mistake 4: Assuming PSD2 and eIDAS 2.0 Are Automatically Aligned

  The fourth mistake is especially relevant for banks and payment service providers.

  The EUDI Wallet will become relevant to identification and authentication flows in regulated digital services. For private-sector relying parties, including banking and financial-services providers, acceptance obligations apply where strong user authentication for online identification is required by Union or national law or by contractual obligation, subject to the Regulation’s timing, scope, user-request, and enterprise-size conditions. (EUR-Lex)

  But eIDAS 2.0 and PSD2 are different frameworks. They do not automatically align.

  PSD2 Strong Customer Authentication has its own legal and technical requirements. It is not simply a requirement to use two factors. Under the RTS, SCA involves two or more elements from the categories of knowledge, possession, and inherence, and those elements must result in an authentication code. For remote electronic payment transactions, dynamic linking also requires the payer to be made aware of the amount and payee, with an authentication code specific to the amount and payee agreed by the payer. (EUR-Lex)

  This creates practical design questions for payment service providers. When a customer uses an EUDI Wallet during a financial-services journey, the organisation needs to know exactly what role the wallet is playing.

  Is the wallet:

  – Identifying the customer?
  – Authenticating the customer?
  – Providing an attestation used inside a broader authentication process?
  – Replacing an existing authentication factor?
  – Supporting authorisation of a specific payment?
  – Contributing to dynamic linking?
  – Supporting a signing step in the journey?
  – Only supporting one step in a larger process?

  These distinctions matter. They affect compliance interpretation, fraud controls, customer experience, evidence, liability, and dispute handling.

  A wallet-based event may support a payment journey without satisfying every PSD2 SCA requirement on its own. Payment service providers should therefore map wallet-enabled flows against PSD2 SCA requirements rather than assuming that eIDAS 2.0 acceptance equals PSD2 compliance.

  This is also a liability and evidence issue. If a wallet-enabled financial-services journey is disputed, the organisation needs to understand which framework governs which part of the event: PSD2, eIDAS 2.0, contractual relying party obligations, wallet provider obligations, payment-service obligations, or future payment-services legislation.

   

  For remote signing, this also affects how evidence is created. If a signature or seal is used inside a financial-services journey, the signing event should not be treated in isolation. It should be linked to the identity, authentication, transaction, and authorisation context that gives the event its legal and operational meaning.

  The risk is not wallet adoption. The risk is architectural over-assumption.

  For banks and payment service providers, wallet integration should be treated as a cross-functional design exercise involving compliance, payments, fraud, security architecture, identity, product, legal, and signing-service teams.

  Readiness Questions

  1) Has the organisation mapped EUDI Wallet use cases against PSD2 SCA requirements?
  2) Is the wallet being used for identification, authentication, authorisation, attestation, signing support, or some combination of these?
  3) Does the payment flow still satisfy dynamic linking requirements where they apply?
  4) Are authentication, authorisation, and signing events evidenced across the full journey?
  5) Is liability clear across wallet provider, relying party, payment service provider, and signing-service roles?
  6) Have PSD2, eIDAS 2.0, fraud, dispute-handling, and signing stakeholders reviewed the architecture together?

• Mistake 5: Leaving Signing Credential and Key Management as an Afterthought

  The fifth mistake is one of the most serious: designing signing workflows before designing signing credential and key management.

  Signing credential management is the foundation of qualified signing and sealing infrastructure. Every other control depends on it.

  If signing credentials are created incorrectly, signing keys are protected inadequately, activation is weak, rotation is poorly evidenced, or revocation does not propagate reliably, the signing service is weakened regardless of how polished the user journey looks.

  For qualified electronic signatures and qualified electronic seals, signature and seal creation data must be created and protected using an appropriate qualified creation device model. Where remote QSCD models apply, the architecture must also support the control, authorisation, separation, and evidence requirements associated with remote signing or sealing.

  This creates architectural requirements around:

  – Signing credential creation;
  – Key generation;
  – Key activation;
  – Sole control;
  – HSM and QSCD integration;
  – Remote signing authorisation;
  – Signing credential lifecycle management;
  – Certificate issuance and binding;
  – Key rotation;
  – Suspension and revocation;
  – Sey destruction;
  – Privileged access;
  – Separation of duties;
  – Key ceremony evidence.

  These controls are not backend details. They determine whether the signing or sealing service can support the required assurance level.

  The wrong sequence is common. An organisation designs the signing journey first. It agrees the customer experience, builds application integrations, and defines service commitments. Only then does it ask whether signing credential management can support the intended qualified service model.

   

  By then, remediation may affect architecture, operations, audit evidence, user experience, certification scope, and vendor responsibilities.

  Signing credential and key management should be designed before signing workflows are finalised. It should involve cryptography specialists, HSM owners, PKI teams, security architects, compliance owners, audit stakeholders, signing-service operators, and operations teams.

  The objective is not simply to store keys securely. It is to govern the full signing credential lifecycle in a way that can be operated, evidenced, and assessed.

  Readiness Questions

  1) Are signing and sealing credentials created and protected in the required environment?
  2) Does the architecture support remote QSCD requirements where applicable?
  3) Are key activation, authorisation, and sole-control mechanisms clearly defined?
  4) Are signing credential lifecycle events fully evidenced?
  5) Can key ceremonies and privileged actions be audited and reconstructed?
  6) Does the signing credential model align with the intended qualified service model?
  7) Are responsibilities clear across the customer, operator, QTSP, and technology vendors?

• Mistake 6: Assuming Existing Security Testing Is Enough

  The sixth mistake is assuming that existing security testing proves eIDAS 2.0 readiness. It does not.

  Penetration testing, vulnerability scanning, application security testing, API testing, and cloud configuration reviews remain important. But they usually focus on conventional security risks: exploitable vulnerabilities, weak access controls, insecure APIs, exposed services, misconfigurations, and common software weaknesses.

  Those tests do not automatically prove that remote signing infrastructure, signing credential controls, audit evidence, and qualified service operations are ready for eIDAS 2.0.

  A signing service can pass a standard penetration test and still have serious readiness gaps. For example:

  – Signing credentials may not be governed under the right lifecycle model;
  – Privileged access paths may not be tested deeply enough;
  – Remote signing authorisation may not be evidenced sufficiently;
  – The signer experience may not prove what the signer saw;
  – Audit logs may be collected but not protected or reconstructable;
  – HSM or QSCD integration may not be reviewed against the intended service model;
  – Failure scenarios may not test the signing and trust-service layer;
  – Incident response may not cover signing-key compromise, certificate revocation, or evidence integrity.

  Security testing for eIDAS 2.0 should extend the existing security programme. It should connect application testing, cryptographic assurance, operational control testing, signing-service testing, and conformity assessment evidence.

  The objective is broader than finding exploitable vulnerabilities. The organisation needs confidence that the remote signing service can operate under the required controls and prove that it did so.

   

  Testing should therefore include scenarios such as:

  – Unauthorised signing attempts;
  – Privileged-user misuse;
  – Failed or incomplete signer authorisation;
  – Key activation failure;
  – Certificate suspension or revocation;
  – Timestamping failure;
  – Document preparation or visualisation failure;
  – Evidence record tampering;
  – Disaster recovery for signing infrastructure;
  – Reconstruction of a historical signing event;
  – Signing policy change and rollback.
  

  This type of testing produces more than security findings. It produces evidence for governance, audit, and assessment.

  Readiness Questions

  1) Does current testing cover the remote signing, sealing, and signing credential layer?
  2) Has HSM or QSCD integration been reviewed against the intended service model?
  3) Are privileged access and key activation paths tested?
  4) Is audit trail integrity tested, not just log collection?
  5) Can the organisation prove what the signer saw, accepted, and authorised?
  6) Do tests produce evidence that supports conformity assessment?
  7) Are incident scenarios involving signing keys, certificates, timestamps, signed documents, and trust services exercised?