"How long will this actually take?" is the first question every customer asks during a deployment kickoff call. The honest answer depends on network complexity — but for a recent seven-site regional retail rollout, the answer was 48 hours from first tap install to the first automatically blocked threat. Here's what those two days actually looked like.
Hour 0–4: Tap Install and Sensor Bring-Up
The deployment engineer and the customer's on-site network admin installed passive taps at the core switch of each of the seven sites, mirroring uplink traffic to a small NGNTA sensor appliance at each location. Because taps are passive, no production traffic was interrupted during install — each site's cutover took under 20 minutes.
Sensors phoned home to the NGNTA management console automatically on first boot, using a pre-provisioned enrollment token. By hour four, all seven sites showed a green "Sensor Online" status on the fleet dashboard.
Hour 4–12: Baseline Traffic Learning
With sensors live, NGNTA's behavioral engine spent the next several hours building a baseline of normal traffic per site: typical protocols, usual destination ranges, expected connection volume by time of day. This baseline is what lets the risk-scoring engine tell "unusual for this specific network" apart from "unusual in general."
During this window the team also connected NGNTA's REST webhook to the customer's existing SIEM, so alerts would eventually land in the same queue analysts already worked from.
$ ngnta-cli fleet status
site sensor baseline alerts(24h)
hq-dc online complete 0
store-014 online complete 0
store-027 online learning 62% --
store-033 online learning 58% --
store-041 online complete 0
store-052 online learning 71% --
store-060 online complete 0Hour 12–30: Tuning Alert Thresholds
Default thresholds get you most of the way there, but every network has its quirks — a point-of-sale system that legitimately talks to a dozen backend services, a legacy inventory scanner that looks noisier than it is. The team reviewed the first wave of low-confidence alerts with the customer's IT lead and tuned a handful of per-site exceptions directly in the console.
This is normally the slowest part of a rollout, and here it moved fast because the customer's team could see the underlying flow evidence for every alert immediately, instead of waiting on a support ticket to get context.
Hour 30–48: First Blocked Threat
At hour 37, the detection engine flagged a source IP running a low-and-slow port scan against store-027's point-of-sale subnet — a pattern the system correctly distinguished from the legitimate backend chatter it had just spent the last day learning. The configured mitigation playbook pushed a block to the site's existing firewall automatically, and the alert landed in the customer's SIEM with full flow evidence attached.
No one had to be paged. The security team reviewed the disposition the next morning during business hours, confirmed it as a true positive, and closed the ticket in under five minutes.
"What surprised the customer most wasn't the speed of install — it was that the first real threat was caught and handled automatically before their own team had even finished the rollout checklist."
Jordan Lee, Deployment Engineer, NGNTA
What Made This Rollout Fast
- Passive taps meant zero production downtime during install, at any site.
- Automated sensor enrollment removed manual configuration at each location.
- Behavioral baselining, not static rules, meant thresholds converged in hours rather than weeks.
- Shared flow evidence let the customer's own team tune alerts without waiting on vendor support.
Most multi-site rollouts don't need months of professional services. They need an architecture that doesn't require touching the live network path, and a detection engine that learns fast. Two days is realistic when both of those are true.
Talk to our deployment team about your own rollout timeline →
Jordan Lee Jordan is a Deployment Engineer at NGNTA, leading multi-site rollouts for retail, healthcare, and financial services customers.