From 17th January 2025, the Digital Operational Resilience Act (DORA) will come into force for all financial organizations in the EU. DORA sets strict requirements for the ICT resilience of financial institutions, and email security plays a crucial role in this.
In this blog, we will investigate DORA requirements concerning email security 'in transit', transport security, the shortcomings of Microsoft 365 (M365) in this context, and additional solutions required to ensure your email security is compliant with DORA.
DORA compliance - Email security requirements
DORA requires financial institutions to ensure the security of data transmission. DORA's key email security requirements include:
- Approved data classification and risk assessment: Data must be classified to ensure that there is appropriate security for different types of information (Article 6, Article 7, Article 13, Article 14).
- Strong encryption of data in transit and at rest: Data must be encrypted both in transit and in its stored state using best-practice encryption (Article 6, Article 7, Article 14).
- Strong recipient authentication: MFA (multi-factor authentication) should be applied to sensitive emails to verify recipients' identities and better secure access to critical data. (Article 20, Article 21).
- Evidence of secure delivery and authorized access: Confidentiality of data during network transmission must be ensured, and procedures in place to assess compliance with these requirements (Article 14). There must also be logging of all events surrounding access to sensitive data (Article 12).
- Measures against human error: ICT solutions must be implemented that protect against the risks of data leaks and human error (Article 9, Article 11).
In this article, we specifically discuss the specific requirements regarding encryption of data in transit, also known as transport security, in relation to email.
Requirements for encryption of data in transit
DORA places a strong emphasis on the encryption of data in transit, as described in Section 6, Encryption and Cryptographic Controls. For example, Article 6(2) states that financial entities must have policies that "regulate all of the following: a. the encryption of data at rest and in transit; Article 14, paragraph 1 stresses that "as part of the safeguards to maintain the availability, authenticity, integrity and confidentiality of data, financial entities must develop, document and implement policies, procedures, protocols and tools to protect information during transmission.".
Good encryption in transit, also known as transport security, should ensure that emails and their attachments are protected from eavesdropping or unauthorized changes during transmission. This is crucial for maintaining the confidentiality and integrity of data when communicating with customers or third parties.
Why using TLS in email isn't secure enough
TLS (Transport Layer Security), or rather StartTLS, is still seen by many as the standard for email encryption or the transport security of email. However, TLS is not nearly as safe as is often thought. One of the drawbacks of TLS is that email clients and servers are not required to cooperate, so security is not guaranteed. This provides room for attackers to carry out a 'downgrade attack', in which the StartTLS capability of a server can be hidden from an email client, so that the email is still sent unencrypted.
In addition, TLS does not offer end-to-end authentication. This means that an attacker can potentially carry out a man-in-the-middle attack and intercept and encrypt emails with their own certificate. This allows attackers to read the content of the emails without the sender or receiver noticing. TLS encrypts the connection between the mail servers during transport, but without proper verification of certificates, there is still a risk of abuse. Therefore, additional security is necessary to ensure that emails are sent and received safely and reliably.
Why DANE is the only secure email standard
DANE (DNS-based Authentication of Named Entities) offers a solution to this problem. DANE is a much more secure method of ensuring that emails are only sent over connections that are secure. It prevents emails from being sent unencrypted, as can sometimes happen with TLS. DANE builds on DNSSEC and provides certainty about the identity of the receiving mail server, drastically reducing the risk of man-in-the-middle attacks. This prevents an attacker from posing as a receiving mail server, allowing him to intercept the mail traffic. It enforces the use of TLS, which prevents an attacker from blocking the StartTLS capability to access unencrypted messages.
Fortunately, Microsoft has recently added support for DANE on incoming email in M365. This means that more and more domains will be implementing DANE in the coming months, making DANE enforcement a realistic option for financial organizations looking to comply with DORA.
Shortcomings in Microsoft's DANE implementation
Microsoft has supported DANE for sending emails in M365 since 2022. However, the default behavior remains opportunistic: the server first tries to connect via DANE, but if the receiving server doesn't support DANE, it automatically switches to TLS or even to a completely unsecured connection. This entails significant risks, especially for organizations that want to strictly comply with DORA.
Although it is possible to configure M365 to allow emails to be sent only via DANE, this poses unworkable practical problems. If the receiving party does not support DANE, the email is simply not delivered and is bounced back to the sender. Since many organizations, including major players such as Google, do not yet support DANE, this could result in a significant proportion of emails being sent back to employees. This means that users have to find other ways to communicate sensitive information, which is obviously not workable in practice.
In short, Microsoft does not provide a secure fallback mechanism if DANE is not supported, for example, to Purview Message Encryption. This is also not on the public roadmap, and will therefore almost certainly not be available in the coming years. This means that financial institutions that want to be fully compliant with DORA cannot be without additional security solutions.
Additional solution for email encryption
The only viable option to ensure compliant transport security of email traffic and meet DORA requirements is to use an additional email security solution. Gartner recommends using an email data protection specialist in addition to the standard security of M365.
Specialist solutions offer advanced email encryption that allows DANE to be enforced with a secure fallback for recipients who don't support DANE. These solutions can handle different levels of security, but if the sender or their organization decides that certain information should be sent using DANE, the solution checks whether the recipient supports DANE, often during the email compose process. If this is the case, enforced delivery takes place via DANE; if not, the email will be delivered via a secure messaging portal with (strong) authentication. This method is not susceptible to the aforementioned 'man-in-the-middle' and 'downgrade' attacks. The strength of the recipient's authentication can be determined by the sender or the organization and can depend on the classification. Examples are two-step verification via email or two-factor authentication via an automated SMS code for (very) privacy-sensitive information.
In addition to being able to enforce DANE, many specialist solutions also offer functionalities in areas where the M365 solution falls short in terms of functionality and user-friendliness. Think of automatic data classification, strong encryption of stored data, strong recipient authentication, preventing data leaks due to human error, and offering file transfer and digital signing. These additional layers of security are necessary to fully comply with DORA requirements while maintaining the operational efficiency of email as a means of communication. In addition, these solutions make it possible to securely digitize traditional paper communications, such as letters, registered mail, and wet signatures. They can also help to bring separate, specific solutions together in an integrated approach.
Conclusion
Adhering to the DORA guidelines for email security goes beyond the standard functionalities of Microsoft 365. Although support for DANE is a step in the right direction, significant limitations remain, such as the opportunistic downgrade to TLS and the lack of an automatic fallback to other encrypted channels such as Purview Message Encryption.
Therefore, it is crucial for financial institutions to make use of additional email security solutions. These solutions not only offer advanced encryption and secure fallback methods, but also additional functionalities such as automatic data classification, strong authentication, and secure digital communication, ensuring that all DORA requirements are met without compromising operational efficiency. In addition, these solutions offer additional benefits, such as the secure digitization of paper communication, the unification of separate solutions in an integrated approach, and the improvement of the user-friendliness and efficiency of secure email communication.
For more information on how to meet compliance with DORA, read our DORA compliance checklist.
Learn how we support compliance with DORA or get in touch for a demo of our Secure Email solution.
