Last year I cut our Snort rule set from 4,200 active rules to 380. The deployment got better at its job. It also got smaller, by design. We kept Snort on three OT segments and two edge choke points where the network was genuinely the right detection layer, and we retired it everywhere else.
The analysts who had been curating those rules shifted to cloud and identity detection, where our actual incidents were happening.
Snort isn't dead in 2026, but it's stuck in the network layer of the stack, and that layer is shrinking fast. CrowdStrike's 2026 Global Threat Report puts malware-free intrusions at 82% of all detections. Cloudflare Radar reports that, over the period analyzed, 98.5% of requests to Cloudflare were encrypted over HTTPS. The adversary doesn't cross your Snort sensor to steal an OAuth token or call AssumeRole.
I'll walk through where Snort rules still earn their rack space, where they've gone blind, what the maintenance math actually looks like once you price it honestly, and the keep/replace/de-scope framework I used to make the call.
In brief:
- Snort rules still work where network is the right detection layer: OT segments running Modbus and DNP3, edge choke points doing inline blocking, and compliance-driven monitoring under PCI DSS 11.4.1 and 11.4.2 or NERC CIP-005 and related NERC CIP standards for Electronic Security Perimeters.
- Snort rules can't see cloud control plane activity, SaaS events, or identity attacks. Microsoft's 2025 Digital Defense Report shows identity-based attacks rose 32% in H1 2025 alone.
- A Snort deployment running thousands of active rules carries a real FTE cost hidden in the analyst queue. If false positives drive most of your triage time, the math stopped working a while ago.
- The 2026 call isn't keep or kill. It's keep narrow, replace broad, and de-scope where duplicate detection exists elsewhere.
What Snort rules actually are in 2026
The textbook answer hasn't changed. Snort is an IDS/IPS. Its rules are detection logic built on a header-plus-options model that matches patterns against network packet payloads and protocol fields in real time.
Cisco Talos publishes rule updates twice weekly with out-of-cycle releases for critical threats, and Snort 3 has been the default engine since FTD 7.0, with Cisco formally deprecating Snort 2 in FTD 7.7.0 as the hard migration forcing function. All true. None of it answers the 2026 planning question.
The 2026 reframe I use is simpler. Snort rules are network-layer signature detection in a stack where less of the meaningful adversary activity touches the network at all. TLS 1.3 has created enterprise visibility challenges for the payload inspection Snort was built to do. Identity attacks transit as normal HTTPS to legitimate endpoints.
Cloud control plane abuse never crosses a wire your sensor sits on. Snort's traffic surface in 2026 is a fraction of what it was in 2018. The planning question I care about is whether what Snort detects still lines up with the incidents my team is actually responding to.
In our environment last year, the answer was "almost never, except in three specific places." That's the math that drove the cut.
Where Snort rules still earn their rack space in 2026
There are environments where network is still the primary detection layer, not a compensating control. In those environments, Snort is load-bearing, not legacy.
The common thread: endpoint agents don't exist, encryption doesn't apply, or a compliance control explicitly requires network IDS. These are the four places I argued for keeping our sensors when we did the scope-down.
- OT and industrial segments: Snort 3 ships six ICS protocol inspectors covering Modbus, DNP3, IEC 60870-5-104, MMS (IEC 61850), CIP/EtherNet/IP, and S7CommPlus. EDR doesn't run on a PLC. IEC 61850 GOOSE messages are typically defined and implemented without encryption because the protocol's strict real-time timing requirements make encryption impractical in most deployments. Snort is the primary available detection mechanism here, not a compensating control. We kept ours on three OT segments for exactly this reason.
- Edge networks and choke-point inline blocking: When you have a single ingress/egress point and you need synchronous block-on-match, Snort in inline mode does the job. Cloud-native equivalents like AWS Network Firewall use a pricing model based on per-endpoint hourly charges and per-GB traffic processed, so the architecture call has cost consequences. We kept Snort on two edge choke points where the inline-block requirement was non-negotiable.
- Budget-constrained environments and MSSP edge sensors: Snort community rules are free. Subscriber tiers can still be workable in some deployments. For some MSP or MSSP edge-sensor models, that math can still hold.
- Compliance-driven monitoring: PCI DSS v4.0.1 Requirements 11.4.1 and 11.4.2 require IDS/IPS coverage and keeping detection engines, signatures, and rules current. NERC CIP-015-1 requires internal network security monitoring for bulk electric systems, effective September 2, 2025, with implementation deadlines in October 2028 and 2030. The auditor wants the line item. Snort delivers it without breaking the budget.
These wins are real but narrow. They don't make Snort a primary detection layer for a modern enterprise IT network, where the incidents are happening at the identity and cloud control plane.
What Snort rules can't see anymore
The gap isn't a tuning problem, because Snort can't be tuned to see what doesn't reach it. The 2026 attack surface has shifted to layers where network-layer signature matching has zero visibility, and once I started mapping our incidents against our rule firings, the mismatch was hard to ignore.
The SANS 2024 SOC Survey found that 34% of enterprise SOCs had zero TLS interception in place, up from 25% the prior year. For those SOCs, Snort's view of modern web traffic is largely limited to connection metadata rather than payload content.
Even with TLS inspection, the dominant 2026 attack patterns don't generate the artifacts Snort signatures match against. Four classes of activity ours was effectively blind to:
- Cloud control plane events: AWS CloudTrail, GCP audit logs, Azure Activity Log. The adversary calls AssumeRole with stolen credentials over HTTPS to an AWS endpoint. Snort sees an encrypted connection to a legitimate Amazon IP, not the IAM abuse on the other end.
- SaaS activity: Okta, M365, Salesforce, GitHub. Snort sees encrypted HTTPS traffic to api.okta.com. It doesn't see the OAuth grant the attacker just created or the MFA bypass they executed. Okta's own threat intelligence documented VoidProxy, an AiTM phishing platform that intercepts authentication flows. At the network layer, the traffic looks identical to a normal login.
- Identity events: Token theft, session hijacking, device code phishing, consent phishing. Microsoft reported over 147,000 token theft attacks in the preceding year, a 111% year-over-year increase. For Entra ID, the attacks that dominate the volume show up in sign-in logs and authentication telemetry, not on a network sensor. Snort isn't on this perimeter.
- Encrypted east-west traffic: TLS 1.3 eliminates RSA key exchange, making retroactive decryption of archived captures cryptographically infeasible. As post-quantum TLS adoption grows, the deep content match Snort was designed for is increasingly foreclosed at scale.
The Mandiant M-Trends 2025 report documents that 34% of initial access vectors were unknown, highlighting logging and detection gaps that better Snort signatures wouldn't have closed.
What maintaining Snort actually costs in 2026
When I priced out our Snort footprint last year, the subscription line item was the smallest part. Paid Snort subscriber tiers aren't the main cost driver for most teams. Even at 50 sensors, annual Talos Business pricing is $19,950. The larger cost was buried in the analyst queue.
Cisco's own 2023 Cisco Live data shows the production operating range spans 700 to 21,000 active rules depending on policy tier. That's a 30x variance, and it defines the curation problem. We sat near the top end of that range, and the alert queue showed it.
A deployment running thousands of active rules generates alerts somebody has to look at. IBM and Morning Consult research found that about 63% of the alerts analysts manually review are false positives or benign events. Additionally, Ponemon Institute data puts the annual cost of false positive triage at $1.27M per organization.
No public benchmark isolates the Snort-specific share of that cost, but when I looked at where our triage hours were going, a meaningful slice of them was Snort false positives nobody was building remediation for.
Opportunity cost is what finally moved me. The Red Canary 2025 Threat Detection Report found that three of the top five MITRE ATT&CK techniques detected were cloud-native and identity-enabled, with Cloud Accounts ranked first. Red Canary observed four times as many identity attacks versus the prior year.
Looking at where our own incidents were coming from, the math was straightforward: every hour my detection engineer spent curating Snort rules was an hour not spent building detections for cloud and identity, where the actual incidents were landing.
How to scope Snort rules down without ripping them out
The framework I used has three columns: keep narrow, replace broad, de-scope where duplicate detection exists elsewhere. The point is to stop paying maintenance cost on rules that aren't earning it, not to rip out every sensor.
Before applying the columns, set the hygiene baseline: detection engineering lifecycles commonly include criteria for revisiting or retiring rules over time. I set up automatic ticketing when a rule hasn't fired in 12 months. For rules that have never fired, I check whether that's because the attack never happened or because the rule is broken.
Both paths lead to a decision.
1. Keep narrow: OT segments running ICS protocol inspectors. Single-purpose edge sensors doing inline blocking at a choke point. Compliance-driven line items for PCI DSS or NERC CIP-015-1 Internal Network Security Monitoring requirements. Prune the rule set to the lowest viable active rule count for the specific environment and protocols present.
The Security over Connectivity policy runs roughly 700 active rules as a documented baseline. I lean on Cisco's Recommended Rules feature to automatically disable rules for vulnerabilities not present on the network.
2. Replace broad: General-purpose network detection in a modern enterprise. Suricata supports port-independent protocol detection and structured EVE JSON logging that can be ingested natively by Google Security Operations and Elastic, and by Splunk via external parsing apps. AWS Network Firewall runs Suricata 7.0 natively since November 2024.
Zeek/Corelight adds protocol-aware NSM logging for investigation context. Sigma rules in your SIEM cover the identity, cloud, and SaaS detection gaps Snort can't reach.
3. De-scope where duplicate detection exists elsewhere: If your EDR catches the lateral movement a Snort rule was catching, and your CASB catches the SaaS abuse Snort never saw, retire the Snort rules that fire on the same scenarios. There's one exception worth keeping.
Infostealers comprised 11.7% of malware tools detected to have bypassed endpoint defenses, and network-only devices (printers, HVAC, cameras) can't run EDR agents. Keep network detection where the endpoint layer genuinely doesn't exist.
When I applied the framework, we went from 4,200 active rules to 380 across five sensors. Two analysts who had been spending much of their week on Snort curation moved to building Sigma rules against Okta and AWS CloudTrail logs.
Our detection coverage for the attack paths actually hitting us improved within the quarter.
What now?
If you're renewing your Talos subscription this quarter, do what I did first: audit the active rule set against 12 months of FMC hit counts, cut every rule that doesn't fire, fires wrong, or duplicates detection you have elsewhere, and renew only on what's left.
That's the rule set worth paying for, and it's the only scope on which the maintenance math holds up.
Frequently asked questions about Snort rules
Are Snort rules still relevant in 2026?
Yes, in specific environments where network is the primary detection layer. OT/ICS segments, edge choke points, and compliance-driven perimeter monitoring are the strongest cases. For general enterprise IT detection, Snort rules address a shrinking share of the attack surface as identity and cloud control plane attacks now dominate.
Should I replace Snort with Suricata?
If you're deploying new sensors, yes. Suricata offers native multi-threading, port-agnostic protocol detection, and structured EVE JSON logging with native SIEM parsers. AWS Network Firewall already runs Suricata 7.0.
Snort 2.9.x rules are partially compatible, but current Snort VRT rules may fail in Suricata, and Snort Shared Object rules won't load at all. If you're already on Cisco FTD running Snort 3, the migration question is different and usually less urgent.
Can Snort rules detect cloud or SaaS attacks?
No. Cloud control plane events (AWS CloudTrail, Azure Activity Log), SaaS activity (Okta, M365, GitHub), and identity attacks (token theft, OAuth abuse, device code phishing) all transit as encrypted HTTPS to legitimate provider endpoints. Snort sees the encrypted connection metadata, not the attack inside it.
Detection for these layers requires identity logs, cloud-native audit logs, and SIEM-based behavioral rules like Sigma.
How many Snort rules should you actually run?
Active rule counts vary widely by policy tier, spanning from tightly scoped policies to much broader ones in production guidance. For most teams, the useful number sits much lower than the default.
A reasonable starting move is the Recommended Rules feature, which auto-disables rules for vulnerabilities absent from your network, paired with a 12-month no-fire threshold to identify stale rules. Most teams I've talked to have room to reduce active rules substantially with tighter scoping.