🔏NIS2 for Trust Service Providers (TSP / QTSP) — deadlines, obligations, fines

TSPs are one of the 8 provider groups explicitly covered by Reg. (EU) 2024/2690 — the first NIS2 implementing regulation, adopted on 17 October 2024 and entering into force on the 20th day after publication [C9]. The Annex sets out 13 technical titles (security policy, risk, incident handling, BCM, supply chain, security in acquisition, anti-malware, network security, cryptography, physical/environmental security, HR, asset management, access control) plus a specific cryptography section aligned with European and international standards (ETSI EN 319 401, ETSI EN 319 411-1, ETSI EN 319 411-2) [C11]. Art. 14 sets strict TSP-specific thresholds for what counts as a "significant incident": unavailability > 1 hour per week, > 1% or > 200,000 users affected, physical access compromise to restricted zones, or impact on integrity/confidentiality/authenticity at > 0.1% or > 100 users [C10]. These thresholds are strict, lower than for cloud, DNS or MSP, given the "global chain of trust" nature — a compromised certificate can be used for MITM across the entire European ecosystem.

QTSPs are required by Art. 20(1) of Regulation (EU) 910/2014 to be audited every 24 months, at their own expense, by an accredited conformity assessment body (CAB) [C12]. The audit report is sent to the supervisory body (in Romania — ADR, the Romanian Digital Agenda Agency) for recognition or maintenance of qualified status. In parallel, Art. 19 of eIDAS (as modified by Regulation (EU) 2024/1183) requires notification to the supervisory body within 24 hours of awareness for any security breach or loss of integrity with significant impact [C8][C12]. NIS2 Art. 23 overlays a second flow: early warning to the CSIRT (DNSC) within 24 hours, detailed notification within 72 hours, final report within one month [C4]. In practice, Romanian TSP operators send a single runbook that feeds both authorities (ADR and DNSC). Failure to meet either of the two windows can trigger both the sanctions under NIS2 Art. 34 (up to EUR 10 million or 2% of turnover for essential entities) [C5] and the loss of qualified status on the Trusted List.

Regulation (EU) 2024/1183 (eIDAS 2.0, adopted 11 April 2024) amends Regulation (EU) 910/2014 and introduces the EUDI Wallet as the central pillar of EU digital identity [C8]. The four implementing regulations adopted on 28 November 2024 and published on 4 December 2024 set out the technical requirements: Reg. 2024/2977 (person identification data and electronic attestations of attributes), Reg. 2024/2978 (notifications), Reg. 2024/2979 (wallet integrity and core functionalities), Reg. 2024/2980 (protocols and interfaces) [C13]. For TSPs operating in Romania, this means two new critical business lines: (a) issuance of Qualified Electronic Attestations of Attributes (QEAA) that will be consumed by citizens' EUDI Wallets; (b) certificates for Relying Parties that will accept attestations from the wallet. Member States are required to make digital wallets available to citizens by the end of 2026 — which means Romanian QTSPs must be operationally ready for this wave of demand by then [C13].

ENISA + JRC + 18 EU national agencies published, in November 2024, a joint statement identifying the transition of critical infrastructures to post-quantum cryptography by 2030 as a top priority, with hybrid solutions (classical + post-quantum) as a mandatory transition step [C16]. For TSPs, that means planning from ROOT CA / Intermediate CA down to subscriber certificates: (a) a full audit of algorithms and key lengths across all active chains; (b) selection of post-quantum algorithms (ML-KEM, ML-DSA, FALCON, SLH-DSA from the NIST FIPS 203-205 standards published in August 2024); (c) a hybrid migration plan — certificates with two signatures (classical + PQ) or dual-stack certificates; (d) compatibility with eIDAS 2.0 Art. 5a and with the EUDI ARF specifications. NIS2 Art. 21(2)(h) already requires "policies and procedures regarding the use of cryptography" as a minimum measure, and Reg. 2024/2690 details what that means operationally [C3][C9]. For the enterprise market that wants native hybrid post-quantum identity, CAI Technology offers CAI-AUTH as an identity-provider SDK with hybrid cryptographic support (see cai_products_relevant).

Most incidents in the global TSP chain have been caused by compromised suppliers (Comodo 2011 [I2], DigiNotar 2011 [I1]) or by Registration Authority affiliates with weak controls. NIS2 Art. 21(2)(d) and Reg. 2024/2690 (Supply chain title) require TSPs to document, evaluate and control all direct suppliers — including HSM manufacturers, CA software vendors, RA partners and middleware developers [C3][C9]. The lessons of Symantec 2017 [I4] and Entrust 2024 [I5] show that systemic breaches of baseline requirements (CA/Browser Forum + ETSI EN 319 411) can lead to browser-level distrust — and for a Romanian TSP whose chain depends on browsers, distrust of an upstream CA is equivalent to loss of business. Concrete controls: MFA authentication for any RA / partner; complete logging and audit trails; HSMs certified Common Criteria EAL4+ or FIPS 140-3 Level 3+; contracts with NIS2-clone obligations for sub-contractors — NIS2 Art. 21(2)(d) requires this directly [C3].

Type: Root CA compromise + issuance of 531 fraudulent certificates used for MITM against Google services in Iran

Impact: The attackers (a player named "ComodoHacker", claimed to be Iranian and later attributed as state-sponsored) compromised DigiNotar in June 2011 and issued certificates for google.com, skype.com, addons.mozilla.org, Microsoft Update and others. Approximately 300,000 Iranian Gmail users were exposed to MITM. DigiNotar went bankrupt in September 2011 — the first major EU CA to fall as a result of operational compromise. ENISA published the "Operation Black Tulip" report — still an active reference on the ENISA page in 2024.

Lesson: DigiNotar ran no anti-virus on its servers and had no network segregation to block lateral movement after the initial compromise. NIS2 Art. 21(2)(b) (incident handling), (e) (network security) and (i) (asset management) cover exactly these requirements; Reg. 2024/2690 details them per technical title [C3][C9]. The lesson for Romanian QTSPs: target-status "compromised" alerting must be active, multi-tiered, with segregation of the CA network from all other systems.

Type: Compromise of an affiliated Registration Authority + issuance of 9 fraudulent certificates for 7 domains

Impact: On 15 March 2011, an affiliated RA in southern Europe (InstantSSL.it) was compromised; the attackers issued fraudulent certificates for mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.com and login.live.com. The attack was attributed to an IP address in Iran. Comodo accelerated the rollout of MFA for all resellers; two further RAs were compromised later but without new certificate issuance.

Lesson: The incident showed that the point of risk is not just the CA root, but also the chain of affiliated RAs. NIS2 Art. 21(2)(d) (supply chain) and (j) (MFA on all administrative access) are exactly what Comodo lacked in 2011 [C3]. For Romanian QTSPs with a network of RA / business-agent partners — NIS2-clone contract clauses, periodic audit, mandatory MFA, centralised logging.

Type: Mis-issued intermediate CA certificate (procedural error) used for MITM against *.google.com

Impact: On 24 December 2012, Google detected a fraudulent certificate for "*.google.com" issued by an intermediate CA linked to TURKTRUST. At least one intermediate certificate was used for "MITM traffic management" on domains not owned by the customer. Google, Mozilla and Microsoft acted in coordination — a Chrome update on 25 December, Firefox suspended the root certificate, and Windows updated the Certificate Trust List.

Lesson: An incorrectly issued intermediate CA certificate has the full authority of the CA root — i.e. it can issue certificates for ANY domain. NIS2 Art. 21(2)(e) (acquisition, development, maintenance) + Reg. 2024/2690 (Cryptography and Access Control) require strict procedural controls on any issuance of intermediate or cross-certificates. For Romanian QTSPs: separation of duties, dual-control on any CA-root operation.

Type: Systemic mis-issuance (initially 127 certificates, final scope >30,000 certificates over years)

Impact: In March 2017, Google Chrome announced an investigation against Symantec following a series of validation failures; the scope grew from 127 to over 30,000 certificates. Google announced incremental distrust across Chrome 66+ versions (March/April 2018), withdrawal of EV status and a maximum validity of 9 months (279 days) for new certificates. Symantec sold the CA business to DigiCert in 2017 — effectively an exit from the market.

Lesson: For a CA, large-scale mis-issuance is fatal — browser distrust is equivalent to total loss of business. ETSI EN 319 411-1 and Reg. 2024/2690 (the "Security in acquisition" title) + Art. 14 (TSP thresholds) are the minimum monitoring framework. For Romanian QTSPs, continuous monitoring on CT logs (Certificate Transparency), alerting on any issuance outside the perimeter, and automatic auditing is the current baseline.

Type: Pattern of compliance failures: delayed revocations, missing incident reports, administrative errors

Impact: Google announced on 28 June 2024 the distrust of Entrust certificates issued after 31 October 2024 (starting with Chrome 127). Mozilla followed on 1 August 2024 with distrust after 30 November 2024 in Firefox. Microsoft and Apple were expected to apply similar measures. Entrust partnered with SSL.com and now effectively acts as a Registration Authority reselling SSL.com certificates. Historically, none of the 14 CAs publicly distrusted has managed to recover trust.

Lesson: The 2024 lesson is that distrust is no longer being paused for large CAs — Google and Mozilla now apply strictly standardised criteria. NIS2 Art. 21(2)(b) (incident handling) + eIDAS Art. 19 (24h notification) + Reg. 2024/2690 Art. 14 (TSP thresholds) all require proactive, transparent reporting. For Romanian QTSPs: an integrated ADR + DNSC incident-response runbook, plus active monitoring of feedback from browser root programmes (Mozilla Root Store Policy, CCADB — Common CA Database).

Regulamentul (UE) 910/2014 (eIDAS 1.0) - cadrul de baza al serviciilor de incredere · Directly applicable from 1 July 2016; consolidated text of 18 October 2024 reflects amendments introduced by Reg. 2024/1183 and NIS2 [C8]

The substantive baseline framework for TSPs/QTSPs. Art. 19 (24h incident notification), Art. 20 (24-month conformity-assessment audit), Art. 21-24 (specific requirements for qualified certificates for signature/seal/website authentication), Art. 25-34 (timestamp + e-delivery), Art. 35-40 (signatures/seals) remain directly applicable. NIS2 does not replace eIDAS; it overlays on cybersecurity. eIDAS audit = ETSI EN 319 401 + EN 319 411-2 + ETSI TS 119 403.

Regulamentul (UE) 2024/1183 (eIDAS 2.0) - European Digital Identity · Adopted 11 April 2024, published in OJ 30 April 2024, in force 20 May 2024 [C8]

Amends Regulation 910/2014 and introduces the EUDI Wallet + new categories of qualified trust services: electronic ledgers, electronic attestations of attributes (QEAA), remote signing services. Recital 50 aligns TSP cybersecurity obligations with the NIS2 Directive [C8]. In practice, any Romanian QTSP wishing to serve the EUDI Wallet use case (certificates for wallet providers, QEAA for user attributes) must already comply with the NIS2 + eIDAS 2.0 + 4 implementing acts (2024/2977-2980) framework.

Regulamentul (UE) 2024/2690 - masuri tehnice NIS2 (acopera TSP direct) · Adopted 17 October 2024, in force 7 November 2024 (the 20th day after publication) [C9]

Unlike telecom, TSPs ARE explicitly covered by Reg. 2024/2690. The Annex contains 13 technical titles operationalising NIS2 Art. 21(2); Art. 14 sets strict TSP-specific thresholds for what counts as a "significant incident" (> 1 hour unavailability, > 1% or > 200,000 users affected etc.) [C10]. DNSC will use this regulation directly in NIS2 audits of TSPs.

Cyber Resilience Act - Regulamentul (UE) 2024/2847 · In force 10 December 2024; mandatory reporting from 11 September 2026; main obligations applicable from 11 December 2027 [C17]

The CRA applies to products with digital elements — including CA software, HSM firmware, electronic-signature middleware, EUDI Wallet applications [C17]. For TSPs, that means a second supply-chain diligence: any product with digital elements used in the chain must be CE-marked under the CRA — which radically changes contracts with HSM vendors and software providers. The NIS2 (process) + CRA (product) combination closes the loop.

ETSI EN 319 401, EN 319 411-1, EN 319 411-2 + ETSI TS 119 403 · Harmonised European technical standards; non-legal but a reference for audit by CABs and supervisory bodies [C11]

EN 319 401 (general policy requirements for TSPs) + EN 319 411-1 (certificate issuance) + EN 319 411-2 (EU qualified certificates) form the technical package against which CABs audit QTSPs. ENISA has aligned Reg. 2024/2690 with these standards — the 13 technical titles of the Annex are mapped directly. Current versions: EN 319 401 V3.2.1 (January 2026), EN 319 411-1 V1.5.1 (April 2025), EN 319 411-2 V2.6.1 (June 2025) [C11].