Qualified Electronic Registered Delivery (QERDS) — Architecture, Compliance, and Integration Guide

Executive summary: This guide explains what a Qualified Electronic Registered Delivery Service is under eIDAS, how it creates legal effects comparable to registered post, and how to integrate it safely. You’ll learn the end‑to‑end flow, evidence handling, security controls, and practical API patterns for a qualified registered delivery service, with specific guidance for QERDS eIDAS integration across the EU.

What QERDS is — and why it matters

• Simple explanation: QERDS is like “registered mail on the internet” with strong identity checks, tamper‑proofing, timestamps, and receipts that courts accept. It proves who sent what to whom, when it was delivered, and that the content didn’t change.
• Detailed explanation: Under eIDAS, a qualified electronic registered delivery service ensures sender and recipient identification, protects transmitted data against loss, theft, or alteration, and provides qualified timestamps and signed evidences for sending and delivery. Operated by a Qualified Trust Service Provider (QTSP), it confers legal presumptions similar to registered postal delivery within the EU.

Legal and trust anchors — the eIDAS context

• Qualified status: Only services audited and listed as qualified in the EU Trusted List can market as QERDS. This status is central to legal effect.
• Identity assurance: Parties are identified using recognized eID methods (e.g., notified eID, qualified certificates, KYC). The service binds identities to transmission events.
• Evidence framework: Proof of sending, delivery, and content integrity is sealed and timestamped to enable non‑repudiation and long‑term validation.
• Cross‑border recognition: QERDS works EU‑wide — evidences issued by a QTSP in one Member State must be recognized across the Union.

Core capabilities — what a qualified registered delivery service must provide

• Strong sender and recipient identification.
• End‑to‑end integrity and confidentiality of content and metadata.
• Qualified electronic timestamps at key lifecycle events.
• Evidence artifacts for submission, acceptance, delivery, and failure.
• Long‑term validation (LTV) with periodic timestamp renewal.
• Secure retention and auditable logs aligned to regulatory requirements.

Reference architecture — from apps to qualified evidence

1. Client applications — business systems initiating deliveries (CRM, ERP, case management).
2. QERDS integration gateway — your secure backend handling APIs, encryption, idempotency, retries.
3. QTSP QERDS platform — the qualified registered delivery service endpoint.
4. Identity and certificates — QES/QSeal certificates, eID, and attribute sources.
5. Time stamping — qualified timestamps for evidence and LTV.
6. Evidence store — WORM‑capable storage for evidence packages and audit trails.
7. Key management — HSM or cloud KMS for keys, with rotation and access control.
8. Monitoring and alerting — SLAs, queue depth, delivery success, evidence freshness.

Message lifecycle — end‑to‑end flow

1. Prepare — identify sender/recipient, gather payloads, classify sensitivity.
2. Protect — encrypt content, hash payload, attach metadata (subject, refs, expiry).
3. Submit — send to QERDS with idempotency key and required identities.
4. Acknowledge — receive proof of submission with a qualified timestamp.
5. Deliver — QERDS authenticates recipient and makes content available.
6. Receipt — obtain proof of delivery (or failure) with qualified timestamp.
7. Retain — archive evidences and maintain LTV via timestamp renewal.

API integration patterns — practical blueprint

• Transport model: Synchronous submission returning a tracking ID, plus asynchronous webhooks for status changes and evidence availability.
• Idempotency: Provide a unique key per transaction to prevent duplicates.
• Large payloads: Use pre‑signed object storage URLs for upload/download.
• Metadata discipline: Include business keys (caseId, contractId) for reconciliation.
• Webhook security: Verify signatures, use mTLS or signed JWTs, and replay protection.
• LTV strategy: Schedule evidence refresh (new qualified timestamps) before crypto expires.

Evidence packages — verification and storage

• Formats you’ll see: CMS/CAdES signatures, ASiC‑E containers, qualified timestamps.
• What to verify: signer’s certificate chain to an EU QTSP, signature integrity, timestamp validity, certificate status (OCSP/CRL), and container hash vs. manifest.
• Where to store: append‑only object storage with versioning, plus a relational index for search; keep chain‑of‑custody logs.
• How to preserve: periodically re‑timestamp evidences to extend LTV and document crypto migrations.

Security and privacy — controls that matter

• Access control: RBAC with least privilege for submission vs. evidence retrieval.
• Transport security: mTLS for API, signed webhooks, TLS 1.2+ with strong suites.
• Data protection: encrypt at rest, envelope keys in HSM/KMS, rotate and log usage.
• PII minimization: include only necessary identity attributes; apply data retention rules.
• Auditability: immutable logs for every state change — who, what, when, and why.
• Resilience: retries with backoff, poison‑queue handling, and graceful degradation.

QERDS eIDAS integration — identity, certificates, and sealing

• Sender signing strategy: use a Qualified Electronic Seal (QSeal) for organization‑initiated deliveries; use Qualified Electronic Signature (QES) if a natural person must author the act.
• Recipient identity binding: rely on recipient enrollment with the QTSP or verified eID; capture and store the identity context returned by the service.
• Certificate lifecycle: automate issuance, renewal, and revocation; monitor validity windows to avoid submission failures.
• Policy mapping: align business processes to the provider’s delivery policies — acceptance windows, fallback channels, and dispute procedures.

EU adoption scenarios — electronic registered delivery EU use cases

• Government‑to‑Business notices, contract awards, and compliance letters.
• Business‑to‑Business contract amendments, IP license notices, service term changes.
• Bank and insurance regulatory communications with provable delivery.
• HR and corporate governance events requiring formal service of notice.

Operations and SLAs — keep it reliable

• KPIs: delivery success rate, median delivery time, evidence availability, LTV freshness, webhook latency, and duplicate prevention rate.
• Runbooks: resubmit on transient failures, escalate on policy rejections, and regenerate evidences after cryptographic migrations.
• Testing: stage environments with synthetic identities, red‑team evidence tampering, and chaos drills on certificate expiry.

Implementation checklist — quick start

1. Select a qualified registered delivery service provider with EU listing.
2. Obtain QES/QSeal certificates and set up mTLS and webhook signing.
3. Build the submission flow with idempotency and large‑file handling.
4. Implement evidence verification and WORM retention with LTV scheduling.
5. Complete DPIA and update records of processing — define retention and access.
6. Pilot with two‑person control, measure KPIs, and iterate on errors.

Comparison — channels for formal notifications

 

Common pitfalls — and how to avoid them

• Mixing QES and QSeal incorrectly — define when each applies and enforce in code.
• Ignoring idempotency — leads to duplicate legal notices; always include unique keys.
• Storing evidences without LTV strategy — plan timestamp renewal cycles.
• Weak webhook security — sign and verify every callback with replay protection.
• Over‑collecting PII — minimize attributes and enforce retention deletion.

Glossary

• QERDS: Qualified Electronic Registered Delivery Service under eIDAS.
• QTSP: Qualified Trust Service Provider operating qualified services.
• QES/QSeal: Qualified signature/seal for persons/organizations.
• ASiC‑E: Associated Signature Container — extended, for bundled signatures and data.
• LTV: Long‑Term Validation of signatures and evidences.

Summary

• QERDS provides legally robust, EU‑wide proof of sending and delivery with integrity and timestamps.
• Integrate via secure APIs with idempotent submissions, signed webhooks, and large‑file handling.
• Treat evidences as high‑value records — verify, retain immutably, and maintain LTV.
• For QERDS eIDAS integration, align identity, certificates, and policies end to end.
• Use this as your blueprint to move from basic electronic delivery to a qualified registered delivery service that stands up in court.