DORA / eIDAS / QTSP — customer deployment flow

Audience: Stella Ops sales / customer success / Compliance / PM, plus customer-side IT ops, customer-side compliance officers, and customer-side legal counsel. Purpose: answer “what does it actually look like when a customer wants DORA-compliant Stella Ops with eIDAS-qualified seals on regulatory submissions” — and which parts are Stella Ops’ work, which parts are the customer’s, and which parts almost never happen at all. Status: authored 2026-05-04 alongside the eIDAS counsel-cycle closure. Aligned with EXEC-20260504-eidas-reference-only-canonical-model.md (counsel-affirmed). Companion docs: eidas-qtsp-posture.md(single-page eIDAS topic narrative); decisions/REG-20260502-eba-dora-incident-framework-4-3.md and decisions/REG-20260502-eba-dora-roi-4-0-errata5.md (DORA non-eIDAS slices); decisions/eidas-counsel-thread-vendor-questionnaire.md and decisions/eidas-counsel-thread-canonical-model.md (audit trail).

1. DORA scope vs eIDAS scope

DORA (EU 2022/2554) is a wide regulation covering ICT risk management for financial entities. It has many parts:

• Incident reporting — major ICT-related incident reports to NCAs in the EBA-published reporting frameworks (4.0 / 4.3). Stella Ops covers this through the EBA DORA REG records and the runtime’s incident-reporting encoder.
• Register of Information (RoI) — third-party ICT contractual arrangements, again in the EBA reporting framework. Same path.
• ICT risk management — controls, monitoring, evidence.
• Threat-led penetration testing — TLPT reports.
• Operational resilience testing.

eIDAS (EU 910/2014) is a separate regulation. It governs electronic identification, signatures, seals, timestamps, qualified trust services, and trusted lists. Qualified electronic seals / signatures / timestamps are the slice that overlaps DORA: when a financial entity submits regulatory artefacts to an NCA, those submissions sometimes need qualified seals.

A QTSP (Qualified Trust Service Provider) is an eIDAS entity that has been admitted to a Member State trusted list. Only QTSPs can issue qualified seals / qualified timestamps / qualified validation services.

So: DORA compliance ≠ eIDAS qualified signing. eIDAS is one slice of one part of DORA. Most of DORA does not touch eIDAS at all.

2. The four roles in a Stella Ops + eIDAS deployment

This is the legal architecture counsel affirmed (see decisions/eidas-counsel-thread-canonical-model.md):

Stella Ops    = on-prem technical software product
                (ships software; never signs anything on the customer's behalf;
                 never issues qualified services; never sees private keys)

Customer      = the financial entity (bank, insurer, etc.) deploying Stella Ops.
                The customer is the operator that bears qualified-service
                representations under eIDAS Articles 33 / 34 / 40.

QTSP          = the Qualified Trust Service Provider. The customer's choice.
                Listed as qualified in a Member State trusted list. Provides
                the actual qualified service (timestamping / validation /
                preservation / sealing).

Customer's    = the customer's own legal counsel. Reviews the deployment
own counsel    posture before any qualified-service representation is made
                to downstream parties (the NCA, auditors). Stella Ops is
                not a substitute for this review.

Stella Ops is not a TSP or QTSP. Stella Ops never makes qualified-service representations. The runtime emits a local claim-control vocabulary (claimed-against:<qtsp-pack-version> / not-claimed:<reason>) that disclaims qualified-service status when the gates are not open.

3. What the customer brings

Banks and other financial entities routinely already have a QTSP arrangement for their existing regulatory signing. The customer arrives with:

1. A QTSP relationship — a contract / agreement with a QTSP that lists their relevant service in a Member State trusted list. The customer chose this QTSP based on jurisdiction, profile (RFC 3161 / CAdES-LTA / etc.), pricing, and their compliance officer’s recommendation. Stella Ops is not in that decision.
2. The QTSP’s trust-material pack — typically downloaded from the QTSP’s customer portal: EU LOTL snapshot in TLv6, Member State TSL snapshots, public signing/TSA certificate chains, OCSP/CRL evidence, service policy identifiers, etc.
3. The QTSP’s HSM (or HSM driver) — most QTSPs ship a PKCS#11 module that exposes the QTSP-controlled keys. The customer points Stella Ops at this PKCS#11 module path.
4. A way to obtain per-transaction evidence — RFC 3161 timestamp tokens, OCSP responses, archive timestamps. Customer chooses one of:
   • Option B: customer obtains evidence directly from the QTSP at signing time (operator-supplied per-transaction).
   • Option C: QTSP provides an operator-local appliance / private endpoint / batch channel.
   • Option D: QTSP provides periodic evidence bundles to the customer.

Every customer’s operations team handles this; Stella Ops support may guide but does not take ownership.

4. What Stella Ops ships (vendor-agnostic)

Stella Ops never ships a QTSP pack, never ships production timestamp tokens, never ships OCSP/CRL evidence, never ships archive timestamps, never ships vendor credentials. Per EXEC-20260504-eidas-reference-only-canonical-model.md, Stella Ops ships:

• Runtime — src/Cryptography/StellaOps.Cryptography.Plugin.Eidas/ with Loader 1 (EidasTrustedListLoader.cs) and Loader 2 (EidasTransactionEvidenceLoader.cs) that consume the customer-supplied pack and per-transaction evidence.
• PKCS#11 plumbing — StellaOps.Cryptography.Plugin.Hsm consumes any compliant PKCS#11 module the operator points it at.
• Claim-state vocabulary — EidasRuntimeClaimState.cs + EidasClaimWording.cs (counsel-affirmed safer wording).
• Fail-closed gates — EidasEvidenceNotProductionReadyException.cs with a typed reason enum covering all loader-state failure modes.
• Operator attestation skeleton — operator-attestations/eidas-operator-agreement-attestation.template.md. Customer fills it in; Stella Ops never signs it.
• Documentation — this doc, eidas-qtsp-posture.md, docs/modules/cryptography/architecture.md§4.8.

The runtime is vendor-agnostic. The pack and the HSM module are vendor-specific (chosen by the customer). The runtime consumes them through standard interfaces.

5. The actual deployment flow

1. Customer (e.g., a bank) buys / deploys Stella Ops with DORA in scope.

2. Customer already has QTSP arrangement                ←── customer's
   (or picks one — banks routinely do).                     relationship,
                                                            not Stella Ops'.
3. Customer's operations team:
   - downloads the QTSP's pack from their portal
   - installs Stella Ops
   - configures:
       Eidas:TrustedList:OfflineTrustMaterialPackPath = <their pack>
       Eidas:TrustedList:OperatorAgreementAttestationPath = <their attestation>
       PKCS#11 module path = <their HSM driver>
       Eidas:TransactionEvidence:RootPath = <per-transaction supply path>
   - authors and signs the operator attestation file
       (the seven counsel-defined acknowledgements)
   - restarts the service.

4. Runtime opens the loaders:
   - Loader 1 reads the QTSP pack at deploy time
   - Loader 2 reads per-transaction evidence at the signing event
   - operator-attestation gate validates the seven acknowledgements
   - If all gates green → emits claimed-against:<qtsp-pack-version>
   - If any gate red  → emits not-claimed:<reason> (fail-closed)

5. Customer's DORA artefacts (incident reports, RoI submissions, etc.)
   get qualified seals via the configured runtime, using the customer's
   QTSP's HSM. Stella Ops never sees private keys or signs anything on
   the customer's behalf.

6. The customer's own legal counsel reviews the deployment posture
   before any qualified-service representation is made to downstream
   parties. Stella Ops is not a substitute for that operator-side
   legal review.

6. What is NOT per-customer

• Counsel cycles. Stella Ops’ counsel cycles (decisions/eidas-counsel-thread-vendor-questionnaire.md, decisions/eidas-counsel-thread-canonical-model.md) ran ONCE for the whole product. They are closed and counsel-affirmed. They do not re-fire per customer.
• Per-vendor modules. Stella Ops does not write a new plugin for every QTSP a customer brings. PKCS#11 is the standard; the existing crypto plugins consume it abstractly. Most credible QTSPs (Thales-using QTSPs, AWS CloudHSM-backed QTSPs, nCipher-backed QTSPs, Sansec / Yunsec-backed QTSPs in SM regions, CryptoPro / Rutoken-backed QTSPs in GOST regions) speak PKCS#11.
• Forwarding the counsel-approved vendor questionnaire. decisions/VENDOR-BRIEF-20260502-eidas-qtsp-redistribution.md is a Stella-Ops-side product artefact for IF/WHEN Stella Ops itself wants to engage a QTSP at the product level (vendor pack vendoring, co-marketing, etc.). It is not sent to each customer’s QTSP. The customer’s QTSP relationship is the customer’s, not Stella Ops’.
• Approving the customer’s QTSP. Stella Ops does not approve customer QTSP choices. The customer’s compliance officer + the customer’s own legal counsel decide. Stella Ops only requires that the QTSP exposes a PKCS#11 interface (or equivalent) that the runtime can consume.

7. When Stella Ops DOES have to do something QTSP-specific

Two narrow cases:

7.1 Customer’s QTSP doesn’t speak PKCS#11 (rare)

If a QTSP uses a proprietary protocol (custom REST API, vendor-specific SDK that bypasses PKCS#11, custom appliance with no standard interface), then Stella Ops needs a per-vendor adapter. This lands as a small targeted code path inside the existing eIDAS plugin tree (src/Cryptography/StellaOps.Cryptography.Plugin.Eidas/), or as a new sibling plugin if the protocol is fundamentally different.

This is uncommon. Most serious QTSPs are PKCS#11-compliant because PKCS#11 compliance is what makes them broadly deployable.

7.2 Stella Ops decides to engage a QTSP at the product level (deliberate, rare)

If Stella Ops decides — for product / partnership reasons, not per customer — to engage a specific QTSP and ship their pack in-repo or in the Offline Kit, OR to co-market a turnkey solution, then:

1. A new EXEC decision is authored that supplements or supersedes EXEC-20260504.
2. The counsel-approved decisions/VENDOR-BRIEF-20260502-eidas-qtsp-redistribution.md is forwarded to that QTSP. No contract / NDA / payment is required for the act of forwarding.
3. The QTSP returns terms (jurisdiction, profile, expiry/renewal, redistribution rights, confidentiality, no-mark-use, operator pass-through). NDA may fire here if proprietary info changes hands.
4. Those terms come back to counsel under decisions/eidas-counsel-thread-vendor-terms.md (a future thread file; not currently pending). Counsel returns a vendor-specific Gate 3 verdict.
5. The QTSP relationship lands. Vendor pack possibly vendored in-repo. NOTICE.md and third-party-licenses/ updated.
6. Per-deployment configuration becomes simpler for customers using that QTSP, but the customer’s QTSP relationship still controls the qualified-service representations.

This is a product-strategy decision, not a customer-driven one.

8. Common misconceptions

9. Sales / customer-success talking points

For customer-facing conversations:

• “Stella Ops is software. Your QTSP is your relationship. We consume their pack and their PKCS#11 module — we don’t sign anything ourselves.”
• “DORA compliance covers more than just qualified signing. The EBA reporting frameworks are the bigger DORA surface; eIDAS qualified seals matter when you submit certain regulatory artefacts.”
• “There’s no per-customer counsel cycle. Our legal architecture is reviewed and counsel-affirmed at the product level. You configure trust material; the runtime emits the appropriate claim state automatically.”
• “If your QTSP exposes PKCS#11 (almost all do), there’s no engineering work — just configuration. If they use a proprietary protocol, that’s a custom engagement we’d scope separately.”
• “The runtime fails closed. If your pack expires, your operator attestation isn’t loaded, or per-transaction evidence is missing, we emit not-claimed:<reason> rather than a misleading ‘qualified’ claim. That protects both of us.”

10. Cross-references

• eIDAS topic narrative: eidas-qtsp-posture.md
• Binding canonical-model decision: decisions/EXEC-20260504-eidas-reference-only-canonical-model.md
• Regulatory asset record (eIDAS pack): decisions/REG-20260502-eidas-qualified-provider-pack.md
• Regulatory asset records (DORA non-eIDAS slices): decisions/REG-20260502-eba-dora-incident-framework-4-3.md, decisions/REG-20260502-eba-dora-roi-4-0-errata5.md
• Counsel cycle threads (for legal audit): decisions/eidas-counsel-thread-vendor-questionnaire.md, decisions/eidas-counsel-thread-canonical-model.md
• Operator attestation skeleton: operator-attestations/eidas-operator-agreement-attestation.template.md
• Vendor questionnaire (if Stella Ops engages a QTSP at the product level): decisions/VENDOR-BRIEF-20260502-eidas-qtsp-redistribution.md
• Runtime architecture: docs/modules/cryptography/architecture.md§4.8
• Decisions folder index: decisions/README.md

Append-only history