NIS2 and DORA documentation for sslbrain

About sslbrain in one page

NIS2, DORA and the other frameworks

• NIS2 is an EU directive, and each country has its own law, for example the Danish NIS 2 Act (Act no. 434 of 6 May 2025) and the Swedish Cybersecurity Act (Cybersäkerhetslag (2025:1506)). The Danish Act entered into force on 1 July 2025. The articles here are the directive's, so the documentation can be used anywhere in the EU.
• Financial entities follow DORA, Regulation (EU) 2022/2554, which takes precedence over NIS2 where it covers the same matters (NIS2 Article 4).
• Customers that are themselves digital infrastructure or MSPs also follow Implementing Regulation (EU) 2024/2690.
• FairSSL itself is not subject to NIS2. This documentation supports your supply chain obligations: NIS2 Article 21(2)(d) and (3), and DORA Articles 28 to 30.
• The same controls cover GDPR Articles 28 and 32 (the data processing agreement and security of processing).
• FairSSL does not hold an ISO 27001 certification. The controls are mapped to ISO/IEC 27001:2022 Annex A and CIS Controls v8.1.
• sslbrain is developed in line with the Cyber Resilience Act, Regulation (EU) 2024/2847.

• NIS2 Directive (EU) 2022/2555
• DORA, Regulation (EU) 2022/2554
• RTS (EU) 2024/1774 on ICT risk management
• ITS (EU) 2024/2956 on the register of information
• Implementing Regulation (EU) 2024/2690
• Cyber Resilience Act, Regulation (EU) 2024/2847

FairSSL as a supplier

• Changes: Updates to the appliance, service agents and deployment agents are signed with a hardware key, and the appliance installs only updates with a valid signature.
• Access: Administrative access is limited to key personnel with role-based access control (RBAC) and least privilege.
• Updates: Security updates to systems and dependencies are installed continuously.
• Incidents: We notify the customer without undue delay and at the latest within 48 hours if a security incident has affected the customer's data or the service. This is also stated in the terms and the data processing agreement. A vulnerability that has been fixed without affecting the customer's data or the service is not an incident (NIS2 Article 6, points 6 and 15).
• sslbrain is developed in line with the Cyber Resilience Act.

Incidents and contract

• We notify the customer without undue delay and at the latest within 48 hours if a security incident has affected the customer's data or the service (terms, section 16, and data processing agreement, section 8).
• Personal data breaches: FairSSL informs you without undue delay and no later than 48 hours after becoming aware of the breach (data processing agreement, section 8).
• Security notices that require action from you are emailed to the account's security recipients, and all notices are at sslbrain.com/en/security-notices/.
• Sub-processors: a new or replaced sub-processor is announced by email and in the change log in section 3. You can object within 30 days of the notice, and if no solution is found, you can terminate the affected services without a remaining contractual commitment.
• Changes that require action from you are announced at least 30 days in advance.
• When you stop: your subscription runs until the end of the paid period, then switches to Free. Closing the Cloud account does not affect data already held on your systems.
• Personal data that FairSSL processes for you is deleted or returned on termination. Deletion from active systems takes place within 30 days; backups are deleted in the regular rotation.
• FairSSL's total liability is limited to what you have paid in the last 12 months.
• Our notification does not replace your own deadlines for significant incidents under NIS2 Article 23 or DORA Article 19: under NIS2, early warning within 24 hours, incident notification within 72 hours and a final report no later than one month after the notification.

Your supplier assessment of sslbrain

Article 21(2)(d) and (3) of the NIS2 Directive and DORA Article 28 ask you to assess your ICT suppliers. The table shows what FairSSL and sslbrain Cloud can and cannot do in your network, alongside an ACME client using a public CA.

The vault key in sslbrain Cloud

Security reviewers ask about it first. Here is exactly what it can and cannot do.

• The appliance vault encrypts private keys with a 256-bit master key generated on the appliance and never sent to Cloud.
• The master key is stored on the data disk only in encrypted form: copies locked with keys from Cloud (the current key and the most recently replaced ones) and one copy locked with the 12 backup words. While the appliance is running, the unencrypted master key is held in memory, not on disk.
• Cloud generates a random key (32 bytes) for each installation and stores it encrypted.
• The key is replaced every time the vault is unlocked through Cloud and every 6 hours.
• Cloud alone decrypts nothing: Cloud holds neither the master key nor your private keys.
• Cloud plus a copy of the data disk or a backup unlocks the keys as long as Cloud still holds the key that locks the copy. Protect the data disk and backups as you would private keys.
• Cloud controls the vault's availability, not its contents: Cloud can refuse to unlock it or lock the appliance. The 12 backup words always unlock it, including a locked appliance, without Cloud. The appliance then stays unlocked until the next restart; anything that goes through Cloud stops, and the emergency account cannot download private keys or backups.
• If Cloud does not respond, an unlocked vault keeps running. After a restart, Cloud or the backup words unlock it.
• If two copies of the same installation are running, you choose in Cloud which one continues. FairSSL support can also approve a takeover from Cloud, and the account's recipients receive an email. The other copy is locked.
• After a restore from a backup, Cloud asks for your approval (or approval from FairSSL support) before unlocking. The 12 backup words unlock it immediately. Cloud deletes replaced keys when they are more than 7 days old and not among the 10 newest, so an older backup or disk copy can only be unlocked with the backup words.

The NIS2 package from your appliance (Professional)

Your own documentation, signed by the appliance: audit log with chain verification, inventory, renewals and failures, policies on the selected date, completed cryptography policy, risk worksheet and incident procedure. On Professional and above, the appliance creates the NIS2 package: one signed file for the period you choose, ready for your auditor.

• The audit log with hashes and the result of chain verification.
• Certificate inventory on the selected date: names, CA, key type and size, expiry and where each certificate is installed.
• Renewals and failures during the period.
• Policies on the selected date: roles and users, who can download private keys, domain lock and update mode.
• Appliance and service agent versions, and whether the signatures are valid.
• A cryptography policy under Commission Implementing Regulation (EU) 2024/2690, point 9.2 of the Annex, completed with your settings.
• A risk worksheet, an incident procedure with the Article 23 deadlines, and the division of responsibilities between you and FairSSL.
• As a PDF and as files you can edit in Word and spreadsheets.
• Every row in the audit log is sent to your SIEM using syslog over TLS, and the latest hash in the chain is stored in sslbrain Cloud.

Regulation (EU) 2024/2690 is binding only on the entities listed in its Article 1 (e.g. cloud, DNS, MSPs, data centres and trust service providers). For others, it is a useful reference.

Development and vulnerabilities

• Updates to the appliance, service agents and deployment agents are signed with a hardware key, and the appliance installs only updates with a valid signature.
• The operating system underlying the appliance (Ubuntu LTS) installs Ubuntu security updates automatically and restarts at 03:00 UTC if needed.
• A version that cannot be verified will not start, and the version that was running is started again. An integration that cannot be verified does not replace the installed one.
• You choose manual or automatic updates on the appliance.
• The code is readable (source-available), so you or a third party can review it.
• Report vulnerabilities to info@fairssl.dk; the contact is listed in sslbrain.com/.well-known/security.txt. Security notices are at sslbrain.com/en/security-notices/.
• We support the latest and previous major versions and give at least 90 days' notice before a version stops receiving security fixes.

Certification and insurance

• FairSSL does not hold an ISO 27001 certification. The controls are mapped to ISO/IEC 27001:2022 Annex A and CIS Controls v8.1.
• FairSSL A/S holds general liability, product liability and professional liability insurance for IT companies with If.

DORA and RTS 2024/1774, Article 7

DORA, Regulation (EU) 2022/2554, applies to financial entities and takes precedence over NIS2 for them (NIS2 Article 4). Article 7 of Commission Delegated Regulation (EU) 2024/1774 on ICT risk management sets requirements for cryptographic keys and certificates. Here are the three paragraphs concerning certificates, verbatim, and how sslbrain covers them.

Paragraphs 2 and 3 (protecting the keys and replacing them in the event of loss or compromise) are covered by the vault and by the ability to renew a certificate with a new key and install it everywhere at once.

DORA Articles 28 to 30: where to find the answer

The section numbers are the same on the page and in the PDF. Whether the service supports a critical or important function is for you to assess.

The register of ICT suppliers

Information for your register of information under Implementing Regulation (EU) 2024/2956.