RadSec

Expanded Definition

RadSec is the use of RADIUS over a TLS-protected transport, typically TCP, to secure authentication exchanges that would otherwise rely on unencrypted or weakly protected UDP traffic. In NHI and IAM environments, it matters because the RADIUS conversation often carries device authentication, network access decisions, and policy attributes that can be sensitive enough to expose identity posture if intercepted. Unlike plain RADIUS, RadSec adds channel confidentiality and stronger integrity for traffic between network access devices, proxies, and policy servers. That makes it especially relevant where credentials, certificates, or attributes are traversing untrusted segments or provider boundaries. The IETF standard for RADIUS over TLS is defined in RFC 6614, but operational guidance still varies across vendors and deployment models. NHI Management Group treats RadSec as a transport hardening control, not a full identity solution, because it protects the session carrying authentication data without replacing strong credential lifecycle practices. The most common misapplication is treating RadSec as a substitute for access policy, which occurs when teams secure the pipe but leave shared secrets, weak certificates, or overbroad RADIUS authorization logic unchanged.

Examples and Use Cases

Implementing RadSec rigorously often introduces certificate-management overhead and network design constraints, requiring organisations to weigh stronger transport security against added operational complexity.

• Enterprise Wi-Fi authentication where access points forward RADIUS requests to a central policy engine over TLS instead of sending them in the clear.
• Branch-network or campus environments that proxy authentication through intermediate nodes and need protection across routed or semi-trusted links.
• Service-provider or federated access architectures where RADIUS traffic crosses administrative boundaries and requires session confidentiality.
• Network access workflows that depend on device identity, certificate validation, or posture checks and must reduce on-path manipulation risk.
• Transition projects documented in the Ultimate Guide to NHIs, where service-account and machine-to-machine governance often extends into network authentication paths.

For standards context, RadSec is best understood alongside RFC 6614, which formalises how RADIUS is transported over TLS. In practice, the design choice is not just encryption versus no encryption, but whether the environment can support certificate issuance, trust-anchor management, and failure handling for the RADIUS path.

Why It Matters in NHI Security

RadSec matters because many NHI programs secure secrets at rest but leave the authentication transport itself exposed. That creates a blind spot: even if a service account, certificate, or endpoint credential is managed well, the surrounding RADIUS session can still leak metadata or be tampered with if it is not protected in transit. This is especially important in environments where network access is a prerequisite for reaching NHI-backed services, such as VPNs, Wi-Fi, bastions, and administrative access gateways. NHI Management Group reports that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which underscores how quickly weak transport controls can turn identity traffic into an exposure path when credentials or attributes are intercepted. RadSec also fits the broader zero-trust direction described in the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0, where secure communication channels support trustworthy access decisions. Organisations typically encounter the operational necessity of RadSec only after a RADIUS relay, proxy, or network-edge compromise, at which point protecting authentication traffic becomes operationally unavoidable to address.