Most of us grew up professionally in a world where “secure access” meant encrypt the tunnel and harden what’s exposed. VPNs, TLS/mTLS, WAFs, EDR, patching, detection, response... the whole modern stack is built around the assumption that the network and its endpoints are visible. Security starts once a connection attempt is already in motion.
The problem is that the internet didn’t get that memo. Our core TCP/IP networking systems were designed to facilitate easy connection, rather than to fend off malicious actors. That default visibility has become a liability in the modern era.
In other words: visibility is vulnerability, especially when attackers (human or machine) can scan, probe, and exploit at machine speed.
Instead of asking “How do we detect bad stuff faster?”, we need to ask a more disruptive question:
What if we didn’t let unauthenticated systems even see what to attack?
That’s the promise of the Network-infrastructure Hiding Protocol (NHP), a specification introduced in our new Stealth Mode SDP for Zero Trust Network Infrastructure publication. NHP is a stealth-driven protocol that applies Zero Trust at OSI Layer 5 (the session layer). It enforces deny-all by default and requires authenticate-before-connect before any real session is established.
Modern Zero Trust solutions often live predominantly at OSI Layers 6 and 7 (presentation and application). Think VPN replacements for encrypted communication and web proxies for application-layer filtering. Those are important, but they don’t change a fundamental property of TCP/IP networks: If a service is exposed, anyone can try to connect to it.
That connection attempt, whether it's successful or not, creates opportunities for:
This is the foundational vulnerability inherent in modern networks: the inherent trust granted to any connection attempt at the 5th layer.
Reactive security models don’t get faster just because attackers do. If exploitation time collapses, then “see it, alert on it, respond to it” becomes an unreliable strategy, especially for internet-facing assets.
Instead, take a preemptive move: reduce the attacker’s opportunities before they can touch anything meaningful.
NHP is the third generation of network hiding technology, evolving beyond:
At a high level, NHP is built to enforce "No authentication, no visibility. No visibility, no attack surface." Unlike TLS/mTLS (which secures communications but still exposes endpoints), NHP is designed to hide ports, IP addresses, and even domain names until policy approves access.
This is not a replacement for everything else. You still need application-layer and runtime controls once access is granted. But this is a powerful layer of prevention that many Zero Trust programs under-emphasize.
If attackers can’t reach your exposed service, they can’t exploit its unknown vulnerability. NHP implements ‘never trust, always verify’ by enforcing ‘deny-all’ rules by default, allowing only authorized hosts to establish connections. This reduces risk from vulnerability exploitation, particularly zero-day exploits.
NHP also targets pre-authentication exposure, which is where a lot of high-impact vulnerabilities live. These include unauthenticated RCEs, pre-auth auth bypass, weak default endpoints, exposed management interfaces, forgotten test services, and more.
If “stealth mode” sounds hand-wavy, here's a workflow to make it concrete:
Yes, NHP contributes to many cryptographic improvements: Noise Protocol Framework, ECC efficiency, identity-based cryptography (IBC), replay resistance, header design, obfuscation fields, and so on.
But from a general IT/security perspective, the bigger strategic point is architectural. NHP moves Zero Trust enforcement earlier in the stack. You verify first, then allow any connection attempt to exist.
NHP renders network resources invisible to unauthorized users. This is a shift from “protect what’s exposed” to “don’t expose it in the first place.” This is the kind of control that scales well against AI-enabled threats, because it reduces the number of tries an attacker can cheaply make.
One of the most interesting extensions of the session-layer idea is how DNS integrates: NHP can tie DNS resolution to a successful authenticated handshake.
Instead of public DNS records advertising where things live or attackers enumerating domains and mapping infrastructure, NHP can use a private domain identifier and resolve it only after authentication. This keeps the resolver only accessible by the NHP-Server and makes domains not publicly resolvable.
If you’re building (or repairing) a Zero Trust roadmap, NHP naturally supports three common goals:
It’s not magic. There are important caveats, like the need for complementary controls post-authentication and operational risk considerations (server availability, key management choices, latency windows).
But if your Zero Trust journey has mostly been identity, proxies, and mTLS at the app layer, you may be leaving a key layer under-protected. Attackers (and their AI tooling) will happily keep knocking on doors you didn’t realize you left visible.
Download and read the full paper for implementation-level depth.
Share this content on your favorite social network today!
Monthly updates on all things CSA - research highlights, training, upcoming events, webinars, and recommended reading.
Monthly insights on new AI research, training, events, and happenings from CSA’s AI Safety Initiative.
Monthly insights on new Zero Trust research, training, events, and happenings from CSA's Zero Trust Advancement Center.
Quarterly updates on key programs (STAR, CCM, and CAR), for users interested in trust and assurance.
Quarterly insights on new research releases, open peer reviews, and industry surveys.
Subscribe to our newsletter for the latest expert trends and updates
We value your privacy. Our website uses analytics and advertising cookies to improve your browsing experience. Read our full Privacy Policy.
Analytics cookies, from Google Analytics and Microsoft Clarity help us analyze site usage to continuously improve our website.
Advertising cookies, enable Google to collect information to display content and ads tailored to your interests.
© 2009–2026 Cloud Security Alliance.
All rights reserved.
