Inspection at Scale: Decryption, Performance, and Security
Encrypted traffic creates a basic security tension. Organizations want confidentiality, but the same encryption can hide malware, command-and-control traffic, data theft, and policy violations from network inspection. Decrypting everything is not a realistic answer. It affects privacy, certificates, application compatibility, appliance capacity, and operational support. The real design problem is deciding where inspection creates enough security value to justify its cost.
The planned source topic was connected to FCSS_EFW_AD-7.6, which Fortinet retired on July 15, 2026. The current NSE 7 Secure Networking 7.6 Architect path continues to require advanced understanding of secure networking. SSL/TLS inspection remains an important example because it forces architects to balance prevention, visibility, performance, and user impact.
At scale, the decision should be policy-driven. Different traffic categories can use certificate inspection, full deep inspection, explicit exemptions, or no interception at all. The correct mix depends on threat exposure, legal and privacy obligations, device trust, application behavior, and available capacity.
Certificate inspection and deep inspection solve different problems
Certificate inspection examines information available from the TLS handshake and certificate without decrypting the application payload. It can support controls based on certificate properties, destination, and other metadata while avoiding full interception. Deep inspection decrypts, inspects, and re-encrypts the session so security engines can examine the protected content.
Deep inspection provides much greater visibility, but it also changes the trust relationship. The firewall becomes an intermediary that presents a replacement certificate to the client. Endpoints must trust the enterprise certificate authority used for that process, and applications that use certificate pinning or unusual TLS behavior may fail.
Architects should therefore avoid treating the two modes as stronger and weaker versions of the same control. They expose different information and create different operational consequences.
The certificate authority becomes critical infrastructure
Full TLS inspection depends on certificate trust. If the enterprise CA used by the firewall is not correctly distributed, users receive certificate warnings or applications refuse connections. If private key material is poorly protected, the inspection system itself becomes a sensitive security asset.
Certificate lifecycle management must include issuance, secure storage, rotation, endpoint distribution, revocation considerations, and ownership. Temporary certificates created during a deployment pilot should not quietly become permanent production roots.
Application teams also need a process to report and validate certificate-related failures. Otherwise, operators may respond to broken applications by adding broad exemptions that weaken inspection far beyond the affected service.
Exemptions should be explicit risk decisions
Some categories of traffic should not be decrypted because of privacy, regulatory, contractual, or technical reasons. Banking, healthcare, personal communications, and certificate-pinned applications are common examples, but the exact policy depends on the organization.
An exemption should identify the reason, owner, scope, and review date. Broad wildcard exemptions are easy to create and difficult to understand later. A growing exception list can turn a deep-inspection project into certificate inspection for most high-value traffic without anyone noticing.
Security teams should also distinguish a privacy exemption from a technical workaround. If an application breaks because of a configuration problem, the long-term answer may be to fix trust or compatibility rather than permanently bypass inspection.
Inspection performance must be measured with the real security stack enabled
Firewall throughput figures are meaningful only when they resemble the intended workload. TLS decryption, intrusion prevention, antivirus, application control, web filtering, logging, and proxy behavior can all affect capacity. Connection rate and concurrent sessions may matter as much as raw bandwidth.
Traffic mix matters too. Many short TLS sessions can create more cryptographic and session-management work than a smaller number of long-lived flows carrying the same bandwidth. Modern cipher suites, certificate chains, HTTP versions, and content patterns can change processing behavior.
Capacity planning should include expected growth and failure conditions. If an HA pair is sized so each member handles only half the normal load, a failover may overload the surviving unit exactly when security controls are most important.
Benchmarking should include the same packet sizes, session rates, cipher suites, and application mix expected in production. A laboratory test that pushes a few large unencrypted flows can dramatically understate the work of decrypting thousands of concurrent browser, API, and collaboration sessions. Logging and inspection profiles should also match production because those controls consume resources and can change the traffic path through the appliance.
Hardware acceleration can complicate troubleshooting
FortiGate platforms can offload eligible traffic to network processors. That improves performance, but it also means some diagnostic commands see only CPU-processed traffic unless offload behavior is considered. Operators who do not understand acceleration can conclude that packets are missing when they are simply being handled outside the expected diagnostic path.
Troubleshooting procedures should identify when to use packet capture, session inspection, debug flow, and NPU-specific diagnostics. Disabling acceleration may be useful in a controlled test, but it should not be treated as a casual production step because it changes performance characteristics.
PrepAway’s Fortinet troubleshooting and high-availability material is a relevant companion because inspection problems often intersect with session state, failover, and platform behavior.
Application compatibility should be tested before broad rollout
TLS interception can expose assumptions that applications normally hide. Certificate pinning, mutual TLS, client certificates, nonstandard ports, embedded devices, thick clients, API integrations, and software updaters may behave differently under inspection.
A staged rollout is safer than enabling deep inspection across the enterprise at once. Start with managed endpoints and a limited user group, collect failures, classify them, and decide whether each issue requires certificate distribution, application configuration, a narrower policy, or a justified exemption.
Change communication matters because users may interpret certificate errors or application failures as general network instability. Support teams should know how to recognize inspection-related symptoms and where to escalate them.
Security profiles should follow risk instead of being stacked mechanically
Once traffic is decrypted, multiple security engines may be able to inspect it. That does not mean every profile should be applied to every flow. Internal backup traffic, administrative access, internet browsing, SaaS applications, and published servers have different threats and performance needs.
Layered inspection should be deliberate. Intrusion prevention may be essential for exploit detection, while web filtering may be more relevant for user browsing. Antivirus can add value for transferred content. Application control may identify unexpected protocols. The policy should explain why each control is present.
The day-to-day operational judgment behind these choices is part of modern firewall administration, which now extends well beyond permit-and-deny rules.
Failure behavior needs the same attention as normal performance
Inspection infrastructure can fail in ways that leave connectivity intact but reduce security. A certificate issue may cause users to bypass controls. A resource shortage may increase latency. An expired subscription or unreachable service can change how a profile behaves. A logging failure may remove visibility while traffic continues to pass.
Teams need to know whether each control is designed to fail open, fail closed, or degrade in another way. That decision should be based on application criticality and business impact. For some high-risk flows, blocking may be correct; for critical services, a controlled degraded mode may be necessary.
Monitoring should therefore include more than appliance CPU. Certificate health, inspection errors, skipped sessions, resource utilization, latency, and user-reported failures can reveal problems before the firewall reaches a hard capacity limit.
Recovery procedures should document what operators do if inspection causes widespread application failures. Disabling deep inspection globally may restore service quickly but can remove important protection from unrelated traffic. A better emergency plan identifies how to narrow the problem to a policy, application category, certificate, or destination and how to apply the smallest temporary exception while the root cause is corrected.
Inspection at scale is a governance program, not a checkbox
A sustainable program defines where decryption is required, where it is prohibited, who approves exceptions, how certificates are managed, how capacity is tested, and how application failures are handled. Those processes are what allow inspection to expand without becoming unpredictable.
Security architecture also needs periodic reassessment because encrypted protocols evolve. New TLS features, client behavior, privacy requirements, and application delivery models can change what is visible and what is practical to intercept.
Practitioners can use the broader Fortinet certifications to connect firewall operations with secure networking, centralized management, and analysis. The durable lesson is that inspection quality depends on engineering trade-offs, not simply enabling the deepest available mode.
Governance should also cover user communication and legal review. Decryption can expose content that users reasonably expect to remain private, and different jurisdictions or business relationships may impose restrictions. Security teams need a documented basis for what is inspected and a process for handling sensitive categories so technical capability does not outrun organizational policy.