Zero Trust Foundations • ZIA • TLS Inspection • Field Notes

A valid certificate proves the channel. It says nothing about the cargo. A platform can only protect the traffic it is able to see.

1. The encryption paradox

Encryption is one of the foundations of digital security. It protects the confidentiality of communications, prevents credentials from being read in transit, and helps users verify the identity of the service they are talking to.

But encryption protects the channel. It does not guarantee that the content travelling through that channel is safe. Malware, phishing, exploits, data exfiltration and unauthorized use of cloud applications all use HTTPS in exactly the same way legitimate services do.

The padlock in the browser confirms that the connection is encrypted and that the certificate presented is associated with the stated destination. It does not certify that the website, the application or the content is safe. Malicious infrastructure can hold a correctly issued certificate, and increasingly does.

Over the last decade, greater privacy awareness, free short-lived certificates and universal TLS adoption have moved the internet towards near-total encryption. That is a good thing for users. It also creates a space where threats stay invisible to controls that cannot inspect content.

A comparison of what a security platform can observe without TLS inspection and with it, and the eight controls that depend on payload visibility
Figure 1. Without decryption the platform still sees the envelope: domain, address, metadata, certificate. With decryption it sees the letter. Eight controls sit on the wrong side of that line until inspection is enabled. Original diagram — Zero Trust Navigator.

This is the difference between knowing that a communication exists and understanding what is happening inside it.

A security platform can only fully protect the traffic it is able to see and analyze.

This article is an introduction to the reasoning behind a TLS Inspection programme: why encrypted traffic is a blind spot, what inspection actually buys, and where the balance between visibility, privacy and business continuity has to be found. It is deliberately not a configuration guide. Certificate architecture, policy design, mobile deployment and troubleshooting each deserve their own deep dive.

2. Why inspection was limited, and what it costs now

TLS Inspection is not a new technology. Historically its main constraint was processing capacity. To inspect an HTTPS connection, a security system has to terminate the client session, validate the destination certificate, present a trusted certificate to the client, establish a second session with the destination, decrypt, run the security engines and re-encrypt before forwarding.

Appliances designed primarily to route and filter often processed a fraction of their nominal capacity once decryption was enabled. Organizations therefore limited inspection to selected categories or user groups. That compromise made sense when HTTPS was a minority of traffic. Today it means excluding the predominant channel of modern business.

The same principle applies to architectures based on virtual appliances or customer-operated cloud instances. Throughput measured without decryption does not represent capacity when every connection must be terminated, inspected and re-encrypted. Depending on the design, inspection may require larger instances, more instances or more aggressive autoscaling.

What it costs with a cloud proxy, honestly

A cloud proxy architecture removes the dependency on the processing capacity of an individual customer-managed appliance. That is a real advantage, and it is where most of the vendor conversation stops. It is not the whole cost.

  • The subscription itself, and the modules whose value only materializes once traffic is decrypted.
  • Using your own enterprise CA rather than the Zscaler private CA is a separate subscription, not a configuration choice.
  • Certificate distribution and lifecycle across every managed and unmanaged device population.
  • Application testing, which is the largest hidden line item and is discussed later in this article.
  • Exception governance: owners, reviews, expiries and compensating controls, indefinitely.
  • Support load during rollout, which is temporary but not small.

Field note: the honest business case is not that inspection is cheap. It is that the controls already purchased are applied to only a minority of traffic until it is enabled. The cost is real, and it buys back something already paid for.

3. How TLS Inspection actually works

In a standard TLS connection, the server presents its certificate, the client verifies the name, the expiry, the signature and the chain back to a trusted root, and the two sides negotiate keys before application data flows.

When inspection is applied, the ZIA Service Edge creates two separate TLS sessions: one between the device and the Service Edge, one between the Service Edge and the destination. The Service Edge validates the original server certificate, then generates a certificate representing that destination and signs it with the intermediate CA configured for the organization. The device accepts it because the corresponding root is in its trust store.

Two TLS sessions with the Service Edge in the middle, the certificate chain from root CA to the dynamically generated certificate, and how keys are handled
Figure 2. Encryption is not removed. Both segments stay encrypted and a controlled inspection point is inserted between them. The certificates issued along the way are deliberately short-lived. Original diagram — Zero Trust Navigator.

Key handling is the part worth reading carefully, because it is what a privacy or risk reviewer will ask about. Operational keys used by Service Edges are held in memory and are not written to disk. The Service Edge intermediate certificate is used for seven days and valid for fourteen. The certificate delivered to the user is used and valid for a single day. If a Service Edge restarts, the keys are erased from memory and must be requested again.

The organization chooses between the Zscaler private CA and an intermediate issued by its own PKI. Functionally the two are equivalent. Operationally they differ in distribution effort, rotation process and, as noted above, commercial terms.

4. What inspection actually buys

With inspection, policy can be applied to the content of a transaction rather than only to its destination: complete URLs, request and response headers, payloads, uploaded and downloaded files, information submitted through forms, actions performed inside cloud applications, and the identity of the tenant being accessed.

The platform stops deciding only whether a destination is allowed. It starts evaluating what the user is doing, what content is moving and in which application context.

  • Inline malware protection, analyzing files and content in the flow.
  • Cloud Sandbox, submitting suspicious files for behavioral analysis.
  • Advanced Threat Protection and IPS, identifying exploits and malicious patterns.
  • Cloud DLP, detecting sensitive information in uploads, forms and transactions.
  • Granular cloud application control, distinguishing upload, download, sharing and posting.
  • File type control, enforcing policy on what moves rather than where it goes.
  • Cloud Browser Isolation, applying isolation decisions to the relevant traffic.
  • Tenant Restriction, separating the corporate instance from everything that looks like it.

Tenant Restriction: allowing the service is not enough

Allowing access to Microsoft 365 or another SaaS platform does not mean allowing access only to the organization’s managed instance. The same approved application can be used to reach a personal account, another organization’s tenant, or to upload corporate documents into an unmanaged environment.

Application-level visibility lets the policy move from one statement to a materially different one:

From “Microsoft 365 is allowed” to “Microsoft 365 is allowed only when the approved corporate tenant is used.”

The destination can be legitimate and trusted while the context in which it is used creates a real risk of data loss. That distinction is invisible without inspection.

5. What inspection still does not see

An honest case for inspection has to state its ceiling. Decryption recovers the transaction, not omniscience.

  • Content encrypted inside the session. A password-protected archive or a payload encrypted by the application before transport arrives as opaque bytes even after the tunnel is opened.
  • End-to-end encrypted messaging where the keys live in the client. Inspection sees a session, not a conversation.
  • Traffic that never reaches the proxy. An unmanaged device on a personal network is not a policy problem, it is a forwarding problem, and no inspection rule fixes it.
  • DNS resolved elsewhere. DNS over HTTPS to an unapproved resolver moves resolution out of view unless it is explicitly controlled.
  • Hostnames before decryption. This one is worth watching.

That last point deserves expansion. A great deal of policy logic, including most bypass rules, depends on reading the destination hostname in the clear during the handshake. Encrypted Client Hello is designed to remove exactly that visibility. As it becomes more widely deployed, decisions that rely on the hostname before decryption will degrade, and designs built entirely on name-based bypasses will age badly.

Design consequence: a policy whose exceptions are all expressed as hostnames is more fragile than one that also uses identity, application context and destination groups. This is a reason to keep the bypass list short that has nothing to do with security theatre.

6. Privacy comes first, not last

In most of the projects where a TLS Inspection programme stalls, it does not stall on certificates. It stalls on people, and specifically on the legitimate question of what the employer is now able to read.

This is not only a policy matter. In the European Union, and particularly in countries with strong workplace protections, monitoring employee activity is regulated. In Italy, rules on remote monitoring of workers mean that a control of this kind is typically discussed with union representatives or authorized by the competent labour authority before it is switched on, not explained afterwards. Treating that conversation as an afterthought is the fastest way to have the programme suspended by someone who does not report to IT.

This article is not legal advice. The point is procedural: involve legal, privacy, HR and workers’ representatives at the start, and let their constraints shape the policy rather than arriving as objections to a policy already built.

What the Acceptable Use Policy has to settle

  • The purpose of inspection, stated in plain language: protection, not surveillance.
  • What data is processed, by whom, and for how long it is retained.
  • Who can access logs, and whether administrator views are obfuscated.
  • Which categories are excluded by principle rather than by technical failure, such as banking, healthcare and other regulated destinations.
  • How a user escalates when a legitimate resource is blocked, and how long a decision takes.
  • How the policy is acknowledged, and how often.

Two supporting artefacts belong in this conversation: the data processing agreement that governs what the provider may access as a processor, and the published privacy documentation that a works council will read whether or not you offer it. Bring them to the table yourself.

Regulatory exclusions and technical bypasses are different objects. The first are decisions the organization has made deliberately. The second are problems it has not solved yet. Never let them share a list.

7. Designing inspection policies

Inspection rules are evaluated from top to bottom until the first match. Specific conditions and exceptions therefore have to sit above broad inspection rules, and the ordering is not a detail of the implementation. It is the design.

A five-tier rule structure from regulatory exceptions down to handling of undecryptable traffic, with the selectors that combine using AND logic
Figure 3. Inspect by default, with narrowly scoped exceptions above the general rule. When a rule names both a group and a location, both must match before it applies. Original diagram — Zero Trust Navigator.

Two practical points that are easy to miss. Selectors within a rule combine with AND logic, so a rule naming a user group and a location applies only where both are true. And the platform imposes limits on how many users, groups, locations and location groups a single policy can carry, as well as on custom categories, URLs and keywords. Check those limits during design rather than discovering them during rollout.

The policy should not become an ever-growing list of bypasses. It should be the mechanism through which coverage expands.

8. Real-world technical limitations

Applications fail under inspection for a small number of reasons, and each one has a different remedy. The single most expensive habit in a rollout is filing every one of them as a generic “SSL issue” and reaching for the same answer.

A decision matrix mapping seven symptoms of inspection failure to their usual cause, the first remediation to try, and the only condition under which an exception is justified
Figure 4. Two rows have no acceptable exception at all, and they are the two most often bypassed anyway: an invalid server certificate is a finding, and QUIC is blocked precisely so that clients fall back to a path that can be inspected. Original diagram — Zero Trust Navigator.

Certificate pinning

Pinning binds an application to a specific certificate or key. The proxy presents a valid certificate signed by a CA the device trusts, but not the object the application expects, so the check fails. Validation happens on the client and there is no universal failure mode: the application may show an error, close silently, send a reset, or simply never transmit application data. The industry has been moving away from the practice, which makes vendor pressure a legitimate remediation rather than a hopeless one.

Application-specific trust stores

Some applications ignore the operating system store entirely and maintain their own. This should be investigated before any bypass is created, particularly for core platforms such as SAP or Oracle. If the product supports adding a custom CA, the application belongs on a remediation roadmap, not on a permanent exclusion list.

Invalid certificates and undecryptable protocols

An expired, revoked or mismatched certificate is not a problem created by inspection. It is a finding. Block the traffic, enable revocation checking, and fix the service. A proprietary or undocumented protocol should likewise not produce an automatic bypass: identify the protocol, the application, the destination, the owner and the business requirement first.

9. Exceptions should be reactive, not preventive

The simplest way to reduce disruption during deployment is to prepare a long list of preventive bypasses. It is also the fastest way to undermine inspection before it has been enabled.

Legacy configurations contain exceptions introduced years earlier, workarounds no longer necessary, and decisions made against the capacity limits of infrastructure that has since been replaced. Use the existing policy as guidance, not as the roadmap.

Exceptions should not be created because an application might fail. They should result from a real, reproducible and documented problem.

Two routes to an exception, a standard investigation path and an emergency path, both ending at the same governance record with an owner and an expiry
Figure 5. Both routes end in the same place. Urgency is allowed to change the order in which the work happens; it is not allowed to remove the record, the owner or the expiry date. Original diagram — Zero Trust Navigator.

When urgency takes control

In practice, exceptions are not always the product of a structured investigation. Inspection breaks an application, a business process stops, and escalation reaches senior management quickly: it worked before, it does not work now, restore it.

A bypass is often the fastest operational response, and restoring a critical process can be the correct decision. The problem is not that the exception was created. The problem begins when an emergency measure is never subsequently investigated, restricted or removed.

Every exception needs an owner and a mitigation

A bypass is not another policy rule. It is risk the organization has accepted, and it should be recorded as such: the affected service and destinations, the business owner and the technical owner, the justification, the evidence, the residual risk, the controls no longer available, the compensating controls, the remediation condition and the review date.

Excluding a flow from inspection does not mean abandoning all controls. Depending on the scenario, compensating measures may include restricting the bypass to specific FQDNs or destination groups, limiting it to named users, device posture verification, strong authentication, endpoint detection or mobile threat defence, DNS and reputation controls, segmentation, protocol restrictions, application-side logging, endpoint DLP or API-based controls.

These are not equivalent to inspection. They reduce residual risk where payload visibility cannot be obtained. Every bypass should produce two artefacts: explicitly accepted risk, and verifiable compensating controls.

Field note: the team administering the platform can maintain the policy, but it should not automatically own every exception. The business owner of the application has to confirm the requirement and participate in removing it.

10. The human factor: visible disruption and invisible risk

When inspection breaks an application, the impact is immediate. The user cannot work, a business process is interrupted, management expects a rapid response, and the apparent cause coincides exactly with the introduction of the security control.

The threat that inspection exists to detect, meanwhile, appears hypothetical. Nobody can prove that on that particular day a specific device would have downloaded malware or exfiltrated a document. The benefit of a security control is usually an incident that never happened. The disrupted application is a present, measurable certainty.

Human decision-making gives more weight to a certain present problem than to a probabilistic future one. So the discussion collapses into a comparison that is not really a comparison:

A possible cyber risk, versus a service that definitely does not work.

This asymmetry is what makes Security look like the function that introduces complexity, delays projects, blocks necessary tools and does not understand the business. That perception is not corrected by stricter policy. It is corrected by explaining which visibility would be lost, which controls would stop operating, which remediation is being investigated, which compensating controls apply and when the decision will be revisited.

The business owner has an equal obligation: to define the real scope required, the real urgency, the actual impact and the available alternatives.

The conversation has to move from “Security is blocking the business” to “Security and the business are jointly deciding which risk to accept temporarily while keeping a critical process running.”

11. The invisible risk is still real

Encrypted threats are less visible. That does not make them theoretical. One incident illustrates the point more precisely than any other, because it is not about an organization that lacked the technology.

Equifax: the control that was configured but not operational

In 2017, attackers exploited an unpatched vulnerability in a consumer-facing portal and went on to access internal systems, taking personal information belonging to roughly 147.9 million people, including names, addresses, dates of birth and Social Security numbers.

Equifax had a system intended to decrypt and inspect encrypted network traffic. The certificate that control required had expired. The inspection capability was therefore inert, and the attackers were able to continue operating for an extended period without their encrypted activity being properly analyzed. The consequences included exposure of identity data on a national scale, executive departures and a settlement with US federal and state authorities of up to $700 million.

The initial cause was a missing patch, not a missing inspection strategy. That is exactly why the case belongs here rather than in a longer list of breach names. It shows that an organization can own the technology, believe the control is in place, and still lose the detection capability entirely because the control was not actually operating on HTTPS traffic.

A security control that is configured but not operational on encrypted traffic is not a partial control. It is a visibility gap with a reassuring name.

This is also the strongest argument for the metrics discussed at the end of this article. “Inspection is enabled” is not a measurement. “This percentage of HTTPS traffic was actually inspected last month” is.

12. Mobile and BYOD: the most complex boundary

Mobile devices combine almost entirely encrypted traffic, applications with independent TLS behaviour and, in BYOD models, hardware that remains the user’s personal property. Two separate problems have to be solved: forwarding the relevant traffic to the service, and getting the operating system and the application to accept the certificate presented during inspection.

Solving forwarding does not guarantee compatibility. Traffic can reach the proxy correctly while the application terminates the session because it does not trust the CA, uses a private store or implements pinning.

A decision matrix of six mobile enrollment models against certificate distribution, forwarding scope and a defensible inspection boundary
Figure 6. The enrollment model decides what you can do. Ownership decides what you should do. On a personally owned device those two answers are deliberately not the same. Original diagram — Zero Trust Navigator.

On iOS, certificates delivered through device management are trusted for TLS automatically, while a manually installed certificate requires the user to enable full trust explicitly. User Enrollment supports certificate payloads and is intended for personally owned devices, which makes selective routing to managed applications the right boundary rather than whole-device inspection.

Android adds a further complication that surprises people: modern applications are not required to trust CAs added by the user. An application must declare through its network security configuration whether it trusts the user-added store. It is therefore entirely possible for the certificate to be installed correctly, the browser to work, forwarding to be correct, and a specific application to reject the connection anyway.

Protect corporate traffic and data without turning a personal device into a fully controlled corporate endpoint.

13. A dedicated mobile testing model

Testing Safari or Chrome does not prove that native applications are compatible. Each critical mobile application has to be exercised properly, and the number of results that implies is the reason exceptions must come out of testing rather than precede it.

A test coverage grid crossing ten application behaviours with five device and enrollment contexts, producing fifty results per critical application
Figure 7. Ten behaviours across five contexts is fifty results for every critical application. That number is the argument: a bypass agreed in advance is a decision taken without any of this evidence. Original diagram — Zero Trust Navigator.

Add corporate, home and mobile networks as a further dimension wherever an application behaves differently on each, and record results per application rather than per domain. A failure affecting one Android application should not silently remove inspection for the same domain on Windows browsers, iOS devices and every other compatible client.

Where a necessary mobile application genuinely cannot be inspected, compensating controls may include deploying it only as a managed application, limiting access to compliant devices, strong authentication and conditional access, mobile application management restrictions on copy, paste, sharing and local storage, mobile threat defence, tenant restrictions and token revocation on loss of compliance. These reduce risk. They do not recreate payload visibility, and the exception stays governed.

14. A sustainable roadmap, and what to measure

Inspection should be implemented progressively. The strategic objective may be maximum coverage, but the route has to preserve operational continuity, and the programme does not end when the policy is switched on.

Seven phases from sponsorship and privacy through to continuous exception reduction, with twelve metrics that show whether the programme is working
Figure 8. Phase seven has no end state, which is the point. Applications, threats and obligations keep moving, so the balance is recalibrated rather than reached. Original diagram — Zero Trust Navigator.

Two phases are consistently underestimated. The pilot should not consist only of IT and development staff: technical users work around problems instead of reporting them, and their application mix is not representative. And problems during rollout should be classified rather than grouped: missing root CA, application-specific trust store, pinning, mutual TLS, smart-card authentication, invalid server certificate, unsupported protocol, regulatory restriction, obsolete application, configuration error. A category is the beginning of a fix; a generic label is the beginning of a bypass.

Optimization then becomes routine: review bypasses on a schedule, distribute the CA to compatible core applications, update incompatible services, replace legacy protocols, validate compensating controls, and use inspection data itself to identify legacy services before progressively enforcing modern TLS versions.

The most important measure is not how many rules have been configured. It is how much relevant traffic is actually being analyzed, at what business cost, and with which residual risks.

There is no universal number

The value of inspection and the cost of a bypass are not identical for every organization or every flow. For one, the temporary unavailability of an application is an inconvenience. For another it stops production, prevents payments, interrupts healthcare or blocks logistics.

It is therefore unrealistic to claim that every exception is always wrong, or that every flow must be inspected regardless of consequence. The objective is not an abstract percentage. It is the highest level of coverage that is genuinely sustainable for that business, continuously reviewed. “Temporarily” remains the critical word, and recognizing business context must not become a way of avoiding remediation.

Final thoughts

TLS Inspection is one of the most valuable capabilities an organization can implement, and one of the most demanding. It is not a policy toggle. It is a programme involving security, networking, PKI, endpoint and mobile management, application owners, privacy, legal, user support and exception governance.

The objective is not to pretend that every flow can be inspected from day one. It is to prevent real limitations from becoming a reason to abandon visibility before anyone has tested what is actually possible.

Exceptions should be reactive, specific, owned, mitigated and reviewed. Emergency bypasses may be necessary, but urgency changes the order of the work, not the accountability.

The fact that a blocked service is immediately visible does not make the threat inside an encrypted session hypothetical. It only makes it quieter. An organization can own the technology, believe the control is in place, and still be blind, as Equifax was, because the control was not actually operating.

A platform can protect what it can see. TLS Inspection is what turns HTTPS from a blind spot into a controlled inspection point, and it is what makes the rest of the security stack something more than a line on an invoice.

Certificate architecture, policy design, mobile deployment, application compatibility, exception governance and troubleshooting will each be examined separately in future Zero Trust Navigator deep dives, at the level of detail production environments require.

Sources and references

Discover more from Zero Trust Navigator

Subscribe now to keep reading and get access to the full archive.

Continue reading