The Zero Trust Architecture (ZTA), as defined by NIST Special Publication 800-207, includes two applicable tenets to TLS. The property of provable security makes a strong case in favour of TLSv1.3.
The first tenet is strong, ubiquitous encryption. Strong encryption is intended to be in transit, at rest, and during compute or compute is isolated in an enclave — a trusted execution environment. TLSv1.3 applies to encrypted data in transit. This means encryption is in use that cannot be intercepted, including by an authorized service. The reason is that this authorized service or mechanism to allow for interception creates a point of potential vulnerability.
TLSv1.3 went through a lengthy review process to ensure the protocol is provably secure. There are regular updates made as needed to ensure that remains the case, which includes preparations for post-quantum cryptographic algorithms as well as addressing any vulnerabilities discovered over time. TLSv1.2 will not support post-quantum encryption, a consideration for roadmap planning.
The second is strong authentication. TLS (all versions) contains features that cross several layers of the protocol stack between the application at Layer 7 and the transport layer (for example, TCP) at Layer 4. The session and presentation layer are both covered as encryption is negotiated between the two connecting hosts, and the protocol implementation includes rich features such as strong authentication.
Mutual TLS (mTLS) is an option that can be enabled in all TLS libraries that have been implemented to assist with building a secure connection with PKI certificate-based authentication. Mutual means that both ends of the connection (client and server) authenticate to each other. Password authentication is also possible, but it is not secure. You can add additional forms of authentication, such as one-time password (OTP) solutions or WebAuthn, with the use of additional libraries. WebAuthn, also known as passkeys and PKI, are considered phishing resistant.
While strong authentication is available in TLSv1.2, the protocol did not go through the rigorous research-based process to be called provably secure, as was done for TLSv1.3. Several critical changes occurred in the TLSv1.3 standard to set these two versions apart, leading TLSv1.3 to be a better fit for meeting the requirements of a ZTA. This is why NIST and others had set dates to deprecate use of anything earlier than TLSv1.3 several years back. Since TLSv1.2 is still secure with appropriate configurations, other governments have allowed for additional flexibility for roadmap planning.
Changes continue to be made, updating TLSv1.3 to prevent interception and ensuring connections using TLSv1.3 are strong and provably secure. As stated above, TLSv1.2 is still considered secure when configured correctly and can be used in environments considered part of a ZTA. The Zero Trust tenets on isolation to prevent lateral movement should be considered in the long-term roadmap towards implementing Zero Trust. Using Zero Trust Network Access (ZTNA) to access individual applications across separate networks enhances isolation, as does employing a routing overlay protocol like GENEVE with IPsec to secure traffic and maintain network segmentation.
Guidance for securely configuring TLS 1.3 is documented in RFC 9325, including recommendations on cipher suites, which are also listed in the IANA TLS Parameters registry. It’s important to note that IANA registries are the most current source of parameter information, such as recommended cipher suites and key sizes, because they are continuously maintained. In contrast, RFCs represent a point-in-time publication and may contain errata or be updated or obsoleted by newer documents linked from the original.
TLSv1.3, coupled with strong authentication, meets the requirements for Zero Trust application access. A core belief of Zero Trust is that you do not trust other layers, such as infrastructure or communication protocols. TLS provides that level of security so that, if configured correctly, organizations don’t need to rely on Wi-Fi (or avoiding Wi-Fi) or other controls to protect their systems, applications, and data. If an organization still requires a VPN, it may still be in transition to a Zero Trust architecture. Once applications can all be accessed using strong encryption and authentication, the requirement for the universal access VPN should fall away in favour of isolated secure application access following Zero Trust tenets.
VPN concentrators have been targeted in attacks, such as the 2020 incidents exploiting known vulnerabilities, that primarily affected financial institutions. Once compromised, these concentrators granted broad access to all unprotected resources behind them. This highlights the importance of dedicated application-level access in ZTA, where isolating each application helps prevent lateral movement
In summary, a deeper understanding of protocols allows for simpler, more effective security policies, moving beyond legacy controls to embrace modern, built-in protections. When protocols, code, and systems are designed with security at their core — and in some cases, made provably secure — they enable security to become both simplified and invisible. Enterprises must also understand where their data transits and resides, including potential aggregation points, to properly assess business risk.
If you missed the first part of this blog series, read it now.
Kathleen Moriarty is the Founder of SecurityBiaS, a Technology Strategist, CTO, Board Member, Keynote Speaker, Author, CISO, and former IETF Security Area Director. She has more than two decades of experience working on ecosystems, standards, and strategy. Kathleen was CTO at the Center for Internet Security when writing this post.
Adapted from the original at the RSA conference blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.