NIS2 and DORA documentation for FairSSL ACME and API

Most of it is certificate data that becomes public in CT logs when the certificate is issued. Personal data is limited to billing, contacts, login and the IP addresses of ACME clients. Data about your internal environment stays with you, apart from what the installation script reports back.

• The websites, control panel, API, ACME server and database run at Amazon Web Services EMEA SARL in the AWS region eu-central-1 (Frankfurt, Germany). Encrypted database backups are stored in eu-north-1 (Stockholm, Sweden).
• We are actively working to move operational and business systems hosted or owned outside the EU to services both hosted and owned in the EU. The certificate authorities (CAs) depend on the chosen product and are not part of the move.
• Automated system emails are sent via Lettermint B.V. (Netherlands); data is processed and stored in the EU.
• Data minimisation is a control in itself (NIS2 Article 21(2), GDPR Articles 25 and 32): with ACME, FairSSL never has your private key, and your internal environment is only visible through what the installation script reports back. This gives a low risk profile for confidentiality. It does not change the availability requirements under DORA.

For the register of information under DORA Article 28(3) and Implementing Regulation (EU) 2024/2956. Your direct supplier is FairSSL A/S, CVR no. 33075782, Denmark: reseller of TLS certificates, ACME server and API for certificate management. The table lists FairSSL's sub-processors, the same as on the sub-processor list. The certificate authorities DigiCert, GlobalSign and Sectigo act as independent controllers under their own agreements; they and our other suppliers are listed in the privacy policy. You assess whether the service supports a critical or important function in your organisation.

• All changes go through version control, and every deployment to production is traceable in the history.
• Administrative access is restricted to key personnel with role-based access control (RBAC) and least privilege.
• Security updates for systems and dependencies are installed on an ongoing basis.
• We notify the customer without undue delay and no later than 48 hours after a security incident has affected the customer's data or the service. This sentence also appears in the terms of sale. A vulnerability resolved without affecting data or the service is not an incident within the meaning of NIS2 (Article 6(6) and (15)).
• The customer is responsible for backing up its own systems and data, including before FairSSL carries out an installation or remote assistance.
• FairSSL A/S has public liability, product liability and professional indemnity insurance for IT companies with If. Proof of insurance is available on request.
• FairSSL is not ISO 27001 certified. The controls are mapped to ISO/IEC 27001:2022 Annex A and CIS Controls v8.1. An independent assurance report, such as ISAE 3000, can be included in a customer agreement at the customer's expense, subject to agreement.

The controls you manage in the control panel. The default is shown in the last column.

• With ACME, your ACME client generates the private key on your own server, and the key stays there. The ACME server only receives the certificate signing request (CSR) and has no function that accepts a private key.
• If you order a certificate without ACME, FairSSL's CSR service can generate the key and CSR for you. The key is stored encrypted with AES-256, using a key derived from the order and a download password. The password is stored encrypted separately from the key, and downloading requires both the link and the password.
• An hourly job deletes the key 48 hours after the first download, and no later than 60 days after it was generated (30 days if the order is cancelled or the certificate is revoked). You can also delete it yourself using the link and password. Each deletion is logged on the order.
• If you do not want FairSSL ever to have your private key, generate the key yourself or use ACME.

• ACME is an open standard (RFC 8555) supported by all major CAs and ACME clients.
• Switching to another provider requires a new account and EAB with the new provider, validation of the domains, possibly new DNS and CAA records, and the new provider's URL in your ACME client.
• Installed certificates work until they expire, even if FairSSL no longer provides the service. The certificates are stored on your systems and with the CA that issued them.
• The overview of your certificates and ACME clients can be retrieved through the monitoring API, so you have your inventory outside FairSSL.

• fairssl.dk and fairssl.se undergo DigiCert's external vulnerability scan weekly without login. The latest report is available on request. The ACME server responds at fairssl.dk/acme on the same servers as fairssl.dk.
• The CAs are audited annually under WebTrust for CAs or ETSI EN 319 411. The audit covers the CAs' operations and issuance, not FairSSL.
• Send security enquiries and vulnerabilities to info@fairssl.dk. The contact is also listed in /.well-known/security.txt (RFC 9116) on fairssl.dk and fairssl.se.

Article 7 of RTS (EU) 2024/1774 on cryptographic key management requires financial entities to renew certificates before expiry (paragraph 5) and maintain a register of certificates and devices that store certificates (paragraph 4).

• Paragraph 5: the ACME client renews automatically before expiry, and ARI tells the client when to renew. The warning about a client that has stopped using ARI and expiry monitoring detect a renewal that does not happen.
• Paragraph 4, partially: the control panel and monitoring API provide an overview of certificates and ACME clients. You register the devices that store certificates (servers, HSMs, load balancers) yourself.

DORA Articles 28-30 and where to find the answer on this page:

Three layers in each row: what the product helps you with, our own controls, and what you are responsible for.

The questions a supplier assessment typically asks, with our answers. Also available as CSV.