Cisco Secure Firewall TLS Decryption

I've spent countless hours with customers designing and implementing SSL/TLS decryption strategies. In nearly every deployment, there are multiple technical, operational and political hurdles to overcome before decryption ever reaches production. 

Too often, teams either go too broad with decryption or stall due to indecision about what to pursue for a policy, and never begin at all. Organizations become so concerned about the risk of breaking an application that they accept a much larger risk: allowing vast amounts of encrypted traffic to pass through their security controls completely unseen.

Many organizations deploy Cisco Secure Firewall, enable TLS inspection, and consider the project complete. Months later, during a security review or incident investigation, they discover a different reality. Entire categories of traffic have been bypassing decryption, generating little more than basic connection logs, and leaving security teams with no visibility into the applications, content or threats moving through those sessions.

This isn't a configuration guide. Instead, it's a collection of lessons learned from real-world customer conversations that happen after deployment, when the dashboards are populated, the policies are in production and the difficult questions begin. If you're a firewall engineer trying to fine-tune a decryption policy, or a security leader looking to understand what your organization is truly inspecting versus what remains hidden, this article is for you.

Encrypted traffic: good for privacy, hard on security?

Here's the problem in plain terms: depending on the industry, 90–95% of enterprise traffic is now encrypted. While that's a win for privacy, it creates one of the biggest visibility challenges facing modern security teams. That's a great privacy, but at the same time not necessarily a security win.

Malware command-and-control, data exfiltration and lateral movement increasingly, if not exclusively, ride inside TLS sessions that look identical to legitimate HTTPS traffic from the outside.

Cisco Secure Firewall's TLS inspection capability addresses this. It acts as a man-in-the-middle (in the trusted sense), decrypting traffic, inspecting it with Snort 3, running it through AMP for malware analysis and IPS signatures, then re-encrypting and forwarding it. When it works well, it's one of the most powerful inspection capabilities in the enterprise security stack.

When it's misconfigured or when bypass rules are too broad this creates exactly the blind spot decryption was meant to eliminate.

The case for decryption

For security engineers, this is understood. But it's worth framing clearly for leadership audiences: not enabling TLS inspection is a strategic choice to accept reduced visibility, not a neutral default.

Cisco's own Talos threat intelligence team has documented repeated cases of malware families using encrypted channels to evade detection. Ransomware groups use TLS to exfiltrate data. Credential-stealing tools use HTTPS to phone home. Without decryption, your IPS sees the envelope, not the contents.

"If you're investing in a next-generation firewall and not inspecting encrypted traffic, you're leaving significant detection capability on the table."

That said, decryption isn't free, and doing it blindly creates its own risks.

Not all traffic deserves equal treatment

One of the most common conversations we have with customers is about bypass scope. The initial instinct is often to decrypt everything. The operational reality is more nuanced.

Certain categories of traffic carry real risks if decrypted, not from a security standpoint, but from a compliance and legal one. Financial institutions processing banking sessions, healthcare organizations transmitting patient data and legal teams handling privileged communications all have regulatory or legal exposure if those sessions are intercepted, even internally.

Beyond compliance, some traffic simply doesn't benefit from decryption. Windows Update, trusted CDN endpoints and internal applications with pinned certificates are common examples. Decrypting these flows burns CPU cycles and adds latency without meaningful detection value.

The right approach isn't "decrypt everything" or "decrypt nothing." It's a tiered model:

Getting this tiering right is where most organizations need help. The technology supports it but the policy design takes deliberate thought.

Policy order is everything

This is where we see the most common technical mistakes in Cisco Secure Firewall SSL/TLS policy.

FMC evaluates the SSL policy top to bottom. The first matching rule wins. This sounds simple, but in practice, customers frequently create broad "Do Not Decrypt" rules high in the policy that consume far more traffic than intended, effectively bypassing inspection for large swaths of enterprise traffic.

A real example: a customer had a "Do Not Decrypt — Finance Category" rule positioned above a more targeted "Decrypt — Uncategorized HTTPS" rule. Legitimate inspection intent was being overridden because several malicious domains had been miscategorized or hadn't been categorized yet. The bypass rule was eating traffic that should have been inspected.

A few principles that hold up in practice:

• Narrow bypass rules should precede broad decrypt rules. Specific exemptions (individual CAs, named internal apps) belong at the top. Broad category-based bypass rules belong lower, after specific decrypt rules have matched what you care about most.
• Always log on bypass rules. A "Do Not Decrypt" rule with logging disabled is a black hole. Even if you're not inspecting the contents, you want connection events (source, destination, port, volume) feeding your SIEM and XDR platform.
• Validate with packet tracer before production. FMC's packet tracer will tell you exactly which SSL policy rule matches a given flow. Use it. It's one of the most underused diagnostic tools in the platform.

Performance hits are predictable, if you plan for it

TLS inspection is CPU-intensive. This isn't a flaw; it's physics. Decrypting, inspecting and re-encrypting traffic takes compute cycles, and if you haven't sized your firewall for the inspection workload, you'll feel it.

The good news: this is predictable and manageable with the right design. 

Sizing reality check

Cisco publishes throughput figures for TLS inspection across the Secure Firewall appliance portfolio. A platform rated at 10 Gbps of firewall throughput may deliver only 2–4 Gbps of TLS inspection throughput; the delta is significant. Factor this into your hardware sizing conversation.

Intelligent bypass is the primary tuning lever. By carving out high-volume, low-risk traffic from the decryption path, you can dramatically reduce the CPU load on the inspection engine while preserving inspection coverage where it matters. The phased approach we recommend: assess, categorize, policy-build, validate, optimize.

For organizations with high traffic load, balancing across multiple firewalls can also distribute the inspection workload. Worth discussing with your SE whether you need high-throughput decryption.

Bypassed doesn't mean invisible: enter EVE

This is where the conversation gets interesting, and where Cisco has made a genuinely significant investment.

The traditional model of TLS inspection has a binary feel to it: decrypt and inspect, or bypass and go blind. Encrypted Visibility Engine (EVE) breaks that binary.

EVE uses machine learning to analyze the observable characteristics of encrypted flows TLS handshake parameters, cipher suites, certificate metadata, packet timing patterns and traffic behavior without ever decrypting the payload. It produces a process-level fingerprint of the application generating the traffic. In many cases, it can identify not just the application category but the specific software client, version and operating system behind an encrypted session.

For security operations, this changes the calculus on bypass decisions. Traffic you've chosen not to decrypt for compliance reasons  financial APIs, healthcare portals, legal SaaS tools all can still be analyzed by EVE for anomalous behavior. If a session claiming to be a known financial application is exhibiting fingerprint characteristics of a known malware family, EVE flags it.

This is particularly relevant for TLS 1.3 and QUIC traffic. TLS 1.3 encrypts significantly more of the handshake than earlier versions, reducing the metadata available for traditional inspection. QUIC (the protocol underpinning HTTP/3) is increasingly common in enterprise environments and is notoriously difficult to inspect at the payload level. EVE's ML approach operates on the observable handshake and flow behavior rather than the payload, making it effective precisely where traditional decryption-based inspection struggles.

Practically speaking: EVE outputs appear in FMC as application visibility data and can feed Secure Firewall's connection events. Integrating these into your XDR platform (Cisco XDR or a third-party SIEM) gives you a correlation layer that spans both decrypted and bypassed flows.

EVE doesn't replace decryption. But it closes a meaningful portion of the visibility gap on traffic you've intentionally chosen not to decrypt, without the performance overhead or compliance risk of a full TLS proxy.

Logging and accountability still matter

Whether or not you decrypt a flow, the connection event belongs in your data lake.

This is a discipline issue as much as a technical one. We've seen mature security teams with well-tuned decryption policies that have logging disabled on bypass rules because "we're not inspecting it anyway." That logic creates forensic blind spots.

Connection events on bypassed flows give you:

• Volume baselines: sudden spikes in bypassed traffic to a known endpoint are worth investigating.
• Destination inventory: over time, you build a map of what your bypassed traffic is actually talking to.
• XDR correlation context: when an endpoint alert fires, being able to pull the network connection timeline (including bypassed flows) materially improves investigation speed.
• Compliance evidence: for regulated industries, demonstrating that you made an intentional, logged decision to bypass a specific category is very different from having no record at all.

The NetFlow and connection event exports from Cisco Secure Firewall integrate cleanly with Cisco XDR, Splunk, Microsoft Sentinel and most major SIEM platforms. There's no reason bypassed flows should be invisible to your SOC.

Putting it into perspective

Decryption policy design is a high-friction areas in Cisco Secure Firewall deployments. Getting it right requires understanding both the security intent and the operational constraints: compliance requirements, certificate infrastructure, application inventory and hardware sizing all feed into the design.

At World Wide Technology, we've worked through this with Fortune 100 organizations across financial services, healthcare, manufacturing and the public sector. The conversations are always specific to the environment, but the patterns are consistent: organizations that approach decryption with a tiered strategy, log everything, including bypass, and leverage capabilities like EVE as a compensating control will end up with a better security posture and fewer operational surprises.

Tuning your decryption policy?

Our Advanced Technology Center has lab infrastructure to help validate decryption configurations.