Cisco Secure Access - Decryption Architecture

Welcome back! Today we're diving deep into one of the most misunderstood (and frankly, confusing) aspects of Cisco Secure Access – the decryption decision flow. If you've ever scratched your head wondering why IPS and SWG (Secure Web Gateway) have separate decryption settings, or why your Do-Not-Decrypt (DND) lists seem to behave differently depending on which entry point your traffic takes, then this blog post is for you. Buckle up, because we're about to untangle this mess!

Why Two Decryption Engines? The IPS vs. SWG Dilemma

Before we jump into the decision flow itself, we need to understand why Cisco Secure Access has this dual-decryption architecture in the first place. It all comes down to two competing needs:

1. Threat Protection – We need to inspect encrypted traffic for malware, exploits, and command-and-control communications. This is the job of the Intrusion Prevention System (IPS).
   
   
2. Data Privacy – We need to respect user privacy and comply with regulations that prohibit inspection of certain types of traffic (healthcare portals, banking sites, personal webmail, etc.). This is where the Secure Web Gateway (SWG) comes in.

Here's the kicker: these two needs don't always align. You might want the IPS to decrypt everything for maximum threat visibility, but you definitely don't want your administrators to have visibility into users' decrypted banking credentials or health records. Enter the dual-decryption architecture.

The Architecture in a Nutshell

• IPS Decryption = Determines if the "Robot" can see the data for safety checks
  
  
• SWG Decryption = Determines if the "Admin" can inspect/control the data for policy enforcement
  
  

The Decision Flow: Two Different Entry Points

The complexity really kicks in when you realize that the decryption decision flow is different depending on how traffic enters the Secure Access cloud. There are two primary entry points:

1. ZTA/Network Tunnel/RAVPN Tunnel – This is when traffic comes through the Zero Trust Access client, a Network Tunnel, or a legacy Remote Access VPN tunnel
   
   
2. Umbrella Roaming Module (Legacy) – This is the older Umbrella roaming client that predates the unified Secure Client
   
   

Let's walk through the decision flow for each entry point. Fair warning: this is where things get a little mind-numbing, but stick with me!

Entry Point #1: ZTA/Network Tunnel/RAVPN Tunnel

When traffic enters through one of these modern tunnel types, the system first asks: "Is there a global setting to decrypt for IPS?"

If NO (IPS decryption is disabled globally):

• The next question is: "Is IPS enabled in the policy?"
  •    If YES, you get "Limited IPS (no decryption)" – meaning IPS signatures will still run, but only on unencrypted traffic or metadata. No actual payload inspection for encrypted flows.
  •    If NO, traffic flows through without any IPS inspection at all.

If YES (IPS decryption is enabled globally):

• The system checks: "Is the destination in the system default DND list?"
  •    If YES, skip to the SWG decryption decision (more on that in a moment)
  •    If NO, continue...
    
    
• Then it asks: "Is IPS enabled in the policy?"
  •    If NO, skip to the SWG decryption decision
  •    If YES, IPS becomes the decryption trigger – traffic gets decrypted in memory, inspected by the IPS engine, and the decrypted payload is immediately discarded. The IPS never "stores" or "logs" the decrypted data itself, only alerts if a signature matches.

Now, regardless of whether IPS decrypted the traffic or not, we still need to decide if the

SWG gets to decrypt it for policy/visibility purposes:

• "Is Security Profile Decryption enabled in the policy?"
  •    If NO, then no SWG decryption happens. If IPS already decrypted it, the SWG features (DLP, URL filtering, etc.) still can't see the unencrypted payload. This is how you get threat protection without data visibility.
  •    If YES, check: "Is the destination on the Security Profile DND list?"
    
    
    • If YES, no SWG decryption. The traffic was potentially decrypted by IPS, but the SWG won't decrypt/process/log it.
      
      
    • If NO, SWG decrypts and all decryption-dependent SWG features (DLP, file scanning, URL categorization, etc.) can now inspect/log the traffic.

Entry Point #2: Umbrella Roaming Module (Legacy)

For traffic entering through the legacy Umbrella Roaming Module, the flow is simpler (thankfully!). There's no IPS decryption option here – SWG is always the decryption trigger.

• The system asks: "Is Security Profile Decryption enabled in the policy?"
  •    If NO, no decryption happens at all.
  •    If YES, check: "Is the destination on the Security Profile DND list?"
    
    
    • If YES, no decryption.
      
      
    • If NO, SWG decrypts and processes the traffic.

Internet Access Features That Require Decryption

So why does all of this matter? Because many of the fancy features you've enabled in Secure Access won't work unless decryption is enabled. Here are the big ones:

• Intrusion Prevention (IPS) – Requires decryption to inspect HTTP traffic for threats and behaviors. Traffic must be decrypted to inspect HTTP traffic for exploits and behaviors.
  
  
• Security features configured in security profiles – This includes things like:
  •    File inspection and analysis
  •    Anti-malware scanning
  •   SAML Authentication
    
    
• Remote Browser Isolation
  
  
• End User Warning/Block Pages
  
  
• Data Loss Prevention

Why Decryption Fails: The Technical Realities

Even when you have decryption enabled and configured correctly, it doesn't always work. Here's why:

1. Application-Specific Protections

• Certificate Pinning – Many non-browser applications (like Dropbox, Slack, or Microsoft 365 desktop apps) are hardcoded to trust only a specific certificate fingerprint. When the gateway replaces the original certificate with its own "fake" one, the application detects a "hijack" and kills the connection to prevent a Man-in-the-Middle attack.
  
  
• Mutual (Client) Authentication – Some high-security sites require the user's device to present its own certificate to the server. A decryption proxy usually cannot "copy" this client certificate to present it to the server, causing the handshake to fail.
  
  

2. Technical Mismatches

• Unsupported Cipher Suites – If a website uses a very modern or very old encryption method (cipher) that the gateway doesn't understand or support, it cannot unscramble the data.
  
  
• Protocol Mismatches – Failures occur when the client and server don't support a common TLS version (e.g., a client only supports TLS 1.1 while the gateway and server require TLS 1.3).
  
  
• TLS 1.3 Complications – In TLS 1.3, the server's certificate is encrypted during the handshake. The gateway must sometimes use a "probe" connection to learn the server's identity before it can decide whether to decrypt, which can lead to timeouts or errors.
  
  

3. Missing Trust Anchors

• Untrusted CA Certificate – If the organization's Root CA certificate is not installed on the user's device, the browser/app will not trust the certificates generated by the gateway. This results in the "Your connection is not private" error page.
  
  
• Incomplete Certificate Chains – If a web server fails to send its intermediate certificates, the gateway might not be able to verify the site's identity, causing it to block the connection for security.
  
  

4. Protocol Errors

• OCSP/CRL Failures – If the gateway cannot reach the certificate authority to check if a site's certificate has been revoked, it may "fail closed" and block the traffic to protect the user.
  
  
• Session Resumption – If a client tries to resume an old, already-decrypted session that the gateway didn't cache or "remember," the handshake may fail because the encryption keys no longer match.
  
  
  
  

The Privacy Divide: IPS vs. SWG Visibility

Let me drive this point home one more time because it's critical to understand:

• The IPS is a "Black Box" Inspector – The IPS engine decrypts traffic in memory, compares it against a library of Snort-based threat signatures, and then discards the decrypted payload. An admin never sees the "raw" decrypted data; they only see an Alert if a signature is triggered (e.g., "Attack 'X' blocked"). The system is designed for detection, not data capture.
  
  
• The SWG is a "Content" Inspector – The SWG is built for visibility. If you have a Data Loss Prevention (DLP) policy enabled, the administrator can often view "snippets" or full files that triggered a violation in the Secure Access Activity Search. The SWG's job is specifically to show you what data is leaving or entering the organization.

This is why you can (and often should) have different Do-Not-Decrypt lists for IPS vs. SWG. The IPS system default DND list is minimal – it only excludes destinations where decryption would break functionality (certificate pinned apps, mutual TLS sites, etc.). Your SWG DND list, on the other hand, should be much larger and include any destination where you want to preserve user privacy (personal banking, healthcare portals, personal email, etc.).

What's Next?

Alright, I think we've covered this topic sufficiently for now! Hopefully this clears up some of the confusion around when traffic gets decrypted, which engine does the decrypting, and what that means for both security and privacy. Let me know in the comments what you'd like to see next!

Thanks for reading, and remember: when in doubt, the robot checks for bombs, the admin checks for policy violations, and never the two shall meet!

Thanks for reading. Let us know if you have any questions about your security infrastructure at sales@lookingpoint.com.