Here's something I see constantly when working with VCF customers: the distributed firewall is running. There are rules — maybe a few hundred of them, carved out over months by someone who knew what they were doing. Traffic is being filtered. The environment is segmented to some degree.
And yet, vDefend's Security Services Platform (SSP) has never been touched. ATP isn't enabled. Nobody has looked at the IDS/IPS dashboards. NTA has never collected a flow. The advanced threat prevention layer — the part that actually catches lateral movement, C2 beaconing, and exploit attempts in flight — is completely dormant.
This is the real Day 2 gap. Not "the firewall isn't configured." The firewall is configured. The gap is everything sitting above the firewall that customers paid for and never turned on.
DFW = Layer 4 rules. You're blocking ports. That's necessary but not sufficient. vDefend SSP + ATP = Layer 7 inspection, behavioural analysis, and threat intelligence. Most VCF environments are running the former and ignoring the latter entirely.
What the SSP Actually Is
The vDefend Security Services Platform is a dedicated appliance — a purpose-built VM that deploys into your management domain and acts as the brain for advanced security services. It's separate from NSX Manager. It's separate from vCenter. And because it requires its own deployment step and its own licensing, it's the thing that most customers skip.
Once the SSP is running, it unlocks the components that make vDefend genuinely powerful:
- Advanced Threat Prevention (ATP) — distributed IDS/IPS running inline on every ESXi host, signature-based and behavioural detection without hairpinning traffic
- Network Traffic Analysis (NTA) — east-west flow baselining and anomaly detection, ML-driven, no agent required
- Malware Prevention — file inspection at the hypervisor layer, catches threats before they reach the guest OS
- NSX Intelligence (where licensed) — topology visualisation and automated rule recommendations based on observed flows
Without the SSP, none of these work. You have a firewall. With the SSP, you have a security platform.
Why Nobody Gets Here
The SSP isn't surfaced prominently in the NSX Manager UI when you're working in
the distributed firewall section. Most customers find their way to
Security → Distributed Firewall, build their rules, and consider the
job done. The path to SSP is through a different part of the interface entirely,
and it's not obvious unless you already know it exists.
There's also a licensing barrier that catches teams off-guard. The SSP and ATP components require vDefend Advanced Threat Prevention licensing, which is separate from the base VCF entitlement. Before any of this is possible, that needs to be confirmed and the license applied to NSX Manager.
Getting to the SSP: Step by Step
Step 1 — Confirm Licensing
In NSX Manager, go to System → Licenses. You're looking for a
vDefend ATP or vDefend Advanced license in the list. If it's not there, stop —
this is a procurement conversation before it's a technical one. Your CSM or TAM
can pull the entitlement details from the account.
Step 2 — Navigate to Security Overview
From NSX Manager, go to Security → Security Overview. This is the
dashboard that shows the health of the entire vDefend stack — DFW, Gateway
Firewall, and SSP services. If the SSP has never been deployed, you'll see
grayed-out tiles for IDS/IPS and NTA. That's your starting point.
Step 3 — Deploy the SSP Appliance
Go to System → Service Deployments → Intrusion Detection & Prevention.
From here you'll deploy the SSP VM into your management cluster. You'll need to
specify a datastore, a management network, and a size profile (small/medium/large
based on environment scale). The deployment takes around 10–15 minutes.
Don't undersize the SSP. The small profile struggles in environments with more than ~500 VMs once NTA is collecting flows at scale. If in doubt, start with medium. Resizing later requires a redeployment.
Step 4 — Enable IDS/IPS on Transport Nodes
Once the SSP is healthy, go to Security → IDS/IPS & Malware Prevention.
Enable IDS on your transport node clusters — you can scope this to specific clusters
first if you want a staged rollout. Start in Detect mode, not
Prevent. Let the signature engine run for a week and review what it flags before
moving to inline prevention.
Step 5 — Create an IDS/IPS Policy
IDS/IPS has its own policy layer, separate from DFW. Go to
Security → IDS/IPS & Malware Prevention → Rules.
Create a profile that targets your highest-value workload groups — databases,
management VMs, anything internet-facing. Apply the VMware-managed signature
set to start; you can tune it once you've seen what the environment generates.
Step 6 — Enable NTA
NTA is enabled separately under Security → Network Detection & Response.
Once on, it begins collecting east-west flow telemetry and building a behavioural
baseline. Give it 7–14 days before expecting meaningful anomaly detection — it
needs time to understand what "normal" looks like in your environment.
Once NTA has a baseline, the Security Overview dashboard starts showing something genuinely useful: which VMs are behaving anomalously, which flows deviate from the baseline, and which events correlate across the kill chain. This is the capability gap between "we have a firewall" and "we have visibility."
The Conversation to Have With Customers
Most customers don't know what they're missing because they've never seen the SSP dashboards working. The most effective thing you can do in a TAM or customer engagement is show them a live Security Overview with IDS alerts and NTA flows populating. That one screen does more to justify the investment in ATP than any slide deck.
The DFW work they did? That's not wasted — it's the foundation. SSP and ATP are the detection and response layer that sits on top of it. The story isn't "you did security wrong." It's "you built the wall, now let's install the cameras."