Pre-access protection for VPNs & gateways
The objection, answered first
Security by obscurity relies on a secret: a hidden port, an unlisted URL, a magic knock. The moment the secret leaks, the protection is gone. Ghost has no secret to leak.
Every gateway behind Ghost enforces default-deny at the network edge. There is no handshake, no banner, no login page for anyone, including an attacker who knows your exact address. Knowing where the gateway lives gets them nothing.
A route opens only after a user proves they belong to the organization: a corporate-domain e-mail address or an organization-issued PKI certificate. Then Ghost publishes that user's IP to the gateway allowlist, scoped and temporary.
Invisibility isn't the security mechanism. It's the result of it. This is authenticate-before-connect, the core zero trust principle, applied at the network layer.
The objection, answered first
MFA protects the login. It doesn't protect the surface. A reachable gateway answers to every scanner, every exploit kit, every zero-day, before any user ever authenticates. That surface is where gateway breaches start.
Ivanti Connect Secure · exploited pre-auth
Citrix NetScaler · CitrixBleed
FortiGate SSL-VPN · recurring RCEs
GlobalProtect · CVE-2024-3400
Next quarter · ???
How it works
Verification happens before reachability. By the time a packet can touch your gateway, its sender has already proven their identity.
Deny by default
User requests access
Organizational verification
Route opens
Access expires
No revolution, just smart evolution
Ghost sits in front of what you already run. The first gateway is typically protected within about 2 hours, not as a milestone of a multi-quarter migration program.
Your stack stays
FortiGate, Cisco ASA, Palo Alto, Ivanti, Citrix, F5 keep working exactly as they do today. Ghost adds a verification layer, it doesn't replace anything.
Your infrastructure
Deployed in your environment, on-prem or in your cloud. User traffic never routes through anyone else's cloud, ours included.
No network redesign
No new tunnels, no re-architected routing, no agents to mass-deploy across the fleet. Topology stays as it is.
Nothing new for users to learn
One lightweight step before connecting: corporate e-mail confirmation or a certificate already on the device. The VPN client they know stays the same.
Ghost vs SASE / ZTNA suites
SASE is a network transformation program. Ghost is a control you switch on. Both can coexist; only one closes your exposure gap this afternoon.
Vendor briefs
Two pages each: the exposure history of your product, how Ghost integrates with it, and why this is not security by obscurity. Written for security and network teams.
ghost-for-fortigate.pdf
ghost-for-ivanti-connect-secure.pdf
ghost-for-citrix-netscaler.pdf
ghost-for-globalprotect.pdf
ghost-for-cisco-asa.pdf
ghost-for-f5-bigip.pdf
Regulatory tailwind
SASE is a network transformation program. Ghost is a control you switch on. Both can coexist; only one closes your exposure gap this afternoon.
What Ghost is not
Not a patching substitute
An unreachable gateway buys you time and removes opportunistic exploitation, but vulnerable software should still be patched. Ghost shrinks the window; it doesn't close the bug.
Not a full ZTNA platform
Ghost governs who can reach the gateway, not per-application micro-segmentation behind it. If you're heading toward ZTNA, Ghost is a step on that path, not the whole path.
Not magic for every network
Environments behind CGNAT or heavily shared egress IPs need one of Ghost's alternative deployment modes. We'll tell you which one applies to you before you commit to anything.
What Ghost is not