TIC 3.0 compliance: where Policy Enforcement Points fail and what auditors do not check
Geert WarmenbolApril 29, 2026
Key takeaways
TIC 3.0 moved federal network security from centralized TICAP routing to distributed Policy Enforcement Points. Compliance verification shifted from confirming traffic routes to confirming PEP configurations are correct — a harder problem that most audits do not fully address.
CISA TIC 3.0 use case guidance documents define specific capability requirements per deployment model. An agency that implemented TIC 3.0 against the general Security Capabilities Catalog without working through its applicable use cases has likely missed use-case-specific controls.
In Vulnox assessments of TIC 3.0 implementations, the most consistent PEP configuration failure is unrestricted CONNECT method handling — allowing tunneled connections to non-standard ports that bypass content inspection entirely.
TIC 3.0 telemetry requirements are satisfied at the event collection level in most agencies. They are not satisfied at the correlation level: logs from distributed PEPs arrive in different formats and are not normalized, making cross-environment incident reconstruction functionally impossible.
Application whitelisting under TIC 3.0 requires organization-specific approved application definitions, not vendor default policy categories. Agencies that rely on next-generation firewall default application categories have implemented the control mechanism without completing the control.
TL;DR
TIC 3.0 is a more operationally realistic framework than TIC 2.0 because it accommodates cloud and distributed architectures. It is also harder to verify correctly because the compliance burden shifted from a connectivity requirement to a configuration requirement. Most TIC 3.0 assessments confirm that PEPs exist and that security tool categories are deployed. They do not verify that PEP configurations enforce the inspection requirements the Security Capabilities Catalog specifies. That gap is where the actual risk lives.
The compliant PEP that did not inspect
A civilian federal agency completed its TIC 3.0 implementation under the cloud use case guidance. They deployed a cloud access security broker as the primary PEP for SaaS traffic, a cloud-native firewall for IaaS workloads, and a next-generation firewall at the network perimeter for on-premises traffic. The compliance documentation mapped each tool to the Security Capabilities Catalog capabilities it addressed. The audit passed. During a Vulnox assessment, we tested the perimeter NGFW configuration. The firewall was configured to allow CONNECT method requests to any destination port — a default that persists in most out-of-box deployments. An attacker with access to any internal endpoint could tunnel arbitrary TCP traffic to any external destination through port 443 CONNECT, bypassing the content inspection rules the firewall was positioned to enforce.
The auditor had verified that the firewall was present, that SSL inspection was enabled, and that application control policies existed. None of those checks surface the CONNECT method configuration because CONNECT handling is a proxy behavior setting, not an application control policy. The tool was compliant. The configuration was not. The audit methodology did not reach the configuration layer where the bypass lived.
How TIC 3.0 actually works and why the service delivery models change the compliance problem
TIC 3.0, codified in CISA's TIC 3.0 Core Guidance documents published from 2019 onward, reorganized the Trusted Internet Connection program around three service delivery models and a Security Capabilities Catalog rather than a single routing requirement. The traditional model retains the TICAP/MTIPS centralized access point approach for agencies where all traffic can practically route through a central inspection point. The branch and campus model allows distributed internet breakout at specific locations, with PEPs at each breakout point satisfying the Security Capabilities Catalog requirements. The cloud model permits cloud-native security controls as PEPs for traffic to and from cloud environments, using CISA use case guidance documents to define what capabilities apply. The Security Capabilities Catalog lists over 20 capabilities across categories including traffic filtering, access management, intrusion detection, data loss prevention, and telemetry. Each use case guidance document specifies which capabilities are required, recommended, or optional for that deployment type.
Example
The cloud use case guidance — formally CISA's TIC 3.0 Use Case: Cloud — defines capability requirements for agencies using cloud service providers to host data and applications. It specifies that the PEP for cloud-destined traffic must perform traffic filtering at the application layer, maintain session logging at a granularity sufficient to reconstruct access events, and enforce data loss prevention controls for traffic leaving cloud environments. A cloud access security broker that provides visibility into SaaS application usage but is not configured to enforce data loss prevention policies satisfies the visibility component and fails the enforcement component. The use case makes that distinction explicit. Implementations that skip the use case guidance and map directly to the general catalog miss it.
The CONNECT method gap is a proxy configuration problem that appears consistently across NGFWs deployed as TIC 3.0 PEPs. HTTP CONNECT is used by browsers and HTTP clients to establish tunneled connections through a proxy — legitimately for HTTPS but exploitable for any TCP traffic. A firewall that allows CONNECT to port 443 can be manipulated into tunneling non-HTTPS traffic if the destination accepts the connection. A firewall that allows CONNECT to any port creates an unrestricted TCP tunnel capability through the PEP. The TIC 3.0 Security Capabilities Catalog's traffic filtering requirement implicitly covers this because unrestricted tunneling bypasses content filtering, but the specific configuration check is not in standard audit methodologies.
What the assessments find in TIC 3.0 implementations
Assessment base: Vulnox federal agency and contractor TIC 3.0 assessments, 2024-2025
PEP configurations with uninspected traffic paths
In TIC 3.0 assessments, misconfigured proxy and firewall behavior creates traffic paths that bypass the content inspection the PEP is positioned to enforce. The CONNECT method issue is the most common variant. A second pattern is SSL inspection configured to exempt certificate-pinned applications — often legitimate operational tools — that an attacker can exploit by making their traffic appear to originate from an exempted application category. Exemption lists grow over time as operational issues arise and nobody removes entries after the operational issue is resolved.
A PEP with uninspected traffic paths is not enforcing the Security Capabilities Catalog requirements for that traffic. The compliance documentation says inspection is in place. The traffic analysis says otherwise. The gap is invisible to an audit methodology that checks whether SSL inspection is enabled without checking what the exemption list contains or whether CONNECT handling is restricted.
Telemetry that collects events but cannot reconstruct incidents
Agencies route logs from distributed PEPs to a centralized SIEM. Each PEP vendor produces logs in a different schema. Firewall logs include session tuples and policy match data. CASB logs include user identity and application context. Cloud-native security logs include resource identifiers and API call records. Without normalization that maps these schemas to a common event model, a security analyst investigating a cross-environment incident must manually correlate events across three or more log formats with different timestamp conventions. In practice, investigations stop at the PEP boundary where the event is clearest rather than tracing the full path.
TIC 3.0's telemetry requirement exists to support incident detection and response. Log collection that satisfies the retention requirement but cannot be correlated across PEPs satisfies the letter of the capability and fails its purpose. This is the same evidence production problem that appears in every distributed logging deployment — the logs exist, the reconstruction capability does not.
Application whitelisting based on vendor category definitions
Next-generation firewalls classify applications using vendor-maintained signature databases with thousands of application categories. TIC 3.0's application whitelisting requirement means defining which applications are approved for use on agency networks and blocking everything else. Agencies typically enable a vendor category policy — blocking malware, peer-to-peer, and high-risk categories — rather than building an approved application list. The vendor category approach is a blocklist. Application whitelisting is a allowlist. They are opposite control postures. The vendor category approach blocks known bad applications. The allowlist approach permits only explicitly approved applications and blocks everything else including unknown or novel applications.
An attacker using a custom or obscure application protocol not in the vendor signature database — or using a protocol that mimics an approved application — bypasses category-based blocking. The application control capability is deployed. The whitelisting posture it is supposed to implement is not. Auditors checking whether application control is enabled will not detect this because they are checking for the tool, not the control posture.
What TIC 3.0 audits do not reach
Use case applicability analysis
CISA has published multiple TIC 3.0 use case guidance documents covering traditional, cloud, remote user, and branch deployments. Each specifies which capabilities are required versus recommended for that deployment type. Agencies with hybrid environments — some on-premises systems, some in cloud, remote workforce — are subject to multiple use cases simultaneously. Most TIC 3.0 implementations map against the general Security Capabilities Catalog and do not work through each applicable use case. The use case-specific requirements that differ from the general catalog are unaddressed.
PEP capacity and inspection degradation under load
TIC 3.0 compliance is assessed at a point in time. SSL inspection, deep packet inspection, and application-layer filtering have computational costs that scale with traffic volume. NGFWs and proxy appliances are often sized for average load. During peak traffic periods — incident response activity, backup windows, software deployment — inspection may be bypassed or degraded because the appliance cannot sustain full inspection at peak throughput. Compliance documentation does not reflect this dynamic. A PEP that inspects correctly at 40% capacity and drops inspection at 80% is compliant in the audit and non-compliant in practice during the periods when traffic volumes are highest.
Ownership of security capability gaps in multi-cloud environments
Agencies using multiple cloud providers — common in federal environments given FedRAMP authorization distributions — deploy different cloud-native security tools in each environment. The security capability coverage of those tools varies by provider. A capability that is satisfied by a native service in one cloud environment may have no equivalent in another, creating asymmetric security postures across cloud boundaries. Nobody owns the cross-cloud capability gap map because each cloud environment has a separate team and a separate compliance review.
Third-party service traffic and the PEP boundary
Federal agencies connect to a growing population of authorized external services — shared services, interagency data exchanges, authorized commercial services. Traffic to these destinations may flow through dedicated interconnects or direct peering arrangements that bypass the TIC PEP. Whether these traffic paths are within TIC 3.0 scope depends on how the agency has defined its TIC boundary. Most boundary definitions were established for traditional internet traffic and have not been updated to account for interconnects added in subsequent years.
The configuration gap between certification and exploitation
In Vulnox TIC 3.0 assessments, a consistent pattern of unauthorized exceptions accumulates in PEP configurations after initial certification — averaging 40 to 70 per environment within 18 months of deployment
PEP configurations are modified for operational reasons after the initial deployment is certified: SSL inspection exemptions for applications that break under inspection, CONNECT method allowances for tools that require unrestricted proxy access, application category exceptions for business-critical software that falls into blocked categories. Each exception is individually justified. Collectively, they erode the inspection posture the PEP was certified to provide. There is no process for reviewing the exception list after the fact. Exceptions are added. They are not removed. (Vulnox assessment data, 2024-2025)
Over 20 security capabilities in the TIC 3.0 Security Capabilities Catalog, spanning traffic filtering, access management, intrusion detection, data loss prevention, telemetry, and resiliency
The catalog defines required and recommended capabilities per use case. An agency that maps its tool set against the catalog categories without verifying that each tool is configured to deliver the capability will produce a compliance matrix that shows coverage the actual deployment does not provide.
Three TIC 3.0 service delivery models with separate CISA use case guidance documents, each specifying different capability requirements for the applicable deployment type
The traditional, cloud, and remote user use cases are not interchangeable. A cloud use case implementation does not satisfy traditional use case requirements and vice versa. Agencies with mixed environments need to identify which use cases apply to which traffic types and verify capability coverage for each.
The TIC 3.0 implementation that created more bypass risk than TIC 2.0
Common belief
Moving from TIC 2.0 centralized routing to TIC 3.0 distributed PEPs improves security by putting inspection closer to the traffic source and eliminating the latency that caused agencies to route cloud traffic outside TICAP.
What we found
In assessments of agencies that migrated from TIC 2.0 to TIC 3.0, the cloud traffic path improved significantly — lower latency, better user experience, no TICAP routing hairpin. The on-premises PEP configurations that replaced centralized inspection frequently had more bypass paths than the TICAP they replaced, because the agency's firewall team was optimizing for operational availability and the TICAP provider had been optimizing for inspection completeness. Both are valid optimization targets. They produce different security outcomes.
TIC 2.0's centralized TICAP model had one major security property: the inspection chokepoint was operated by a certified TICAP or MTIPS provider under a specific service level agreement, not by the agency's own IT team. The agency's configuration choices did not determine whether inspection happened correctly. The provider was contractually responsible for inspection capability. TIC 3.0's distributed model puts that responsibility back on the agency. The agency configures the PEP. The agency maintains the exception list. The agency determines whether SSL inspection is enforced or degraded. The latency problem is solved. The configuration discipline requirement shifted to an organization that has not historically owned it.
Where TIC 3.0 enforcement and implementation are heading
CISA will publish a PEP Configuration Baseline guidance document within 18 months that specifies minimum configuration requirements — including CONNECT method restrictions, SSL inspection minimum coverage percentages, and log normalization requirements — in response to documented configuration failures in agency TIC 3.0 implementations.
The Security Capabilities Catalog defines what capabilities PEPs must provide. It does not define how those capabilities must be configured. The gap between capability presence and correct configuration is well documented in CISA's own assessment programs. The natural regulatory response is to publish configuration baselines that translate capability requirements into specific configuration parameters, the same pattern CISA followed with its Known Exploited Vulnerabilities catalog and Binding Operational Directives for specific product classes.
Confidence: mediumNo CISA TIC 3.0 PEP configuration baseline guidance published by end of 2026At least one federal agency will experience a confirmed breach where the initial access path exploited an uninspected traffic tunnel through a TIC 3.0 PEP — specifically a CONNECT method bypass or an SSL inspection exemption — within 24 months, and the post-incident review will cite the TIC 3.0 configuration gap explicitly.
The CONNECT method bypass and SSL inspection exemption patterns are documented, consistent, and present in a significant portion of current TIC 3.0 deployments. Attackers operating against federal networks enumerate defense configurations. The bypass path is not novel — it is known in the offensive community and has been used against commercial organizations with equivalent configurations. The conditions for a federal incident exploiting this specific path are present. The post-incident review will name it because the forensic trail through an uninspected tunnel is distinctive.
Confidence: highNo publicly attributed federal agency breach citing PEP configuration bypass as the access mechanism by end of 2027
What agencies say before the assessment — and what is underneath it
We bought a top-tier NGFW from a major vendor. It is TIC 3.0 compliant out of the box.
Root cause:No firewall is TIC 3.0 compliant out of the box because TIC 3.0 compliance depends on configuration, not product capability. Vendors publish compliance matrices that map their product's feature set to Security Capabilities Catalog entries. Those matrices confirm that the product can satisfy the capability requirements when properly configured. They do not confirm that the default configuration satisfies them. Default NGFW configurations are optimized for connectivity and operational availability. TIC 3.0 capability requirements for inspection depth and application control require configuration choices that trade some operational simplicity for inspection completeness. Out of the box means the wrong starting point.
Our SIEM is collecting logs from all PEPs. Our telemetry capability is satisfied.
Root cause:Log collection satisfies the retention component of the telemetry capability requirement. It does not satisfy the correlation and detection components. TIC 3.0's telemetry requirement exists to support incident detection and response. A SIEM ingesting logs from five PEP types in five different schemas, with no normalization layer, no cross-source correlation rules, and no baseline for what normal traffic looks like at each PEP, is a log archive. It is not a detection capability. The distinction matters when an incident occurs and the investigation team needs to reconstruct an attack path that crossed three PEP boundaries.
We completed our TIC 3.0 implementation two years ago. Our compliance is current.
Root cause:TIC 3.0 compliance is a point-in-time assessment against a configuration that changes continuously. Exception lists grow. New applications are added to allowed categories. New cloud services are connected through paths that may not route through the PEP. Software updates change proxy and firewall behavior. An implementation that was correctly configured at certification may have accumulated 60 configuration changes in two years, each individually approved for operational reasons, that collectively eroded the inspection posture the certification assessed. TIC 3.0 compliance is not a status that persists. It is a property of the current configuration.
What TIC 3.0 got right and what the implementation community got wrong
TIC 3.0 is a better framework than TIC 2.0 for the actual threat environment federal agencies face. Centralized TICAP routing for cloud traffic was producing security theater — agencies were routing cloud traffic outside the TIC boundary because the latency was operationally unacceptable, which meant the compliance posture and the actual traffic path had diverged completely. TIC 3.0 acknowledged that reality and built a framework around it. The problem is that the implementation community treated TIC 3.0 as a procurement exercise rather than a configuration discipline exercise. Agencies bought the tools that map to the Security Capabilities Catalog and then delegated configuration to firewall teams optimizing for uptime. The compliance documentation reflects the tool set. The security posture reflects the configuration choices. They are not the same document.
Counterargument
The counterargument is that configuration discipline requires operational maturity that many agencies cannot sustain with current staffing levels, and that a framework requiring ongoing configuration validation is unrealistic for agencies with two-person security teams. That argument is correct about the staffing constraint. It is not an argument against the framework — it is an argument for automation of configuration validation, which is a solvable problem that several tools address. The staffing constraint produces a compliance gap. It does not justify accepting the gap.
One thing to do this week
Pull the current exception list from your primary TIC 3.0 PEP — SSL inspection exemptions, application category exceptions, CONNECT method allow rules. Count the entries. Check when each was added and whether the operational reason for the exception still applies. If you cannot answer those questions for more than a third of the entries, your PEP is operating on a configuration that nobody has fully reviewed since deployment. That review takes an afternoon. The next assessment will find the same entries.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisUS federal cybersecurity frameworks: the complete guide to all 37 mandates
TIC 3.0 compliance requirementsCISA Risk and Vulnerability Assessments
CISA risk and vulnerability assessmentsNational Vulnerability Database Home
National Vulnerability DatabaseNIST Cybersecurity Framework 2.0
NIST Cybersecurity Framework
Frequently Asked Questions
What did TIC 3.0 change from TIC 2.0 and why does it matter for compliance?
TIC 2.0 required all federal internet traffic to route through one of a small number of centralized TICAP or MTIPS access points, which created a single inspection chokepoint but also created severe latency for cloud-destined traffic. TIC 3.0 introduced three service delivery models — traditional, branch/campus, and cloud — and published use case guidance allowing agencies to implement distributed Policy Enforcement Points closer to users and applications. The compliance implication is that the model shifted from connectivity verification to configuration verification. Under TIC 2.0, compliance meant routing traffic through the right provider. Under TIC 3.0, compliance means configuring PEPs correctly across a distributed environment, which is harder to verify and easier to get wrong.
What is a Policy Enforcement Point in TIC 3.0 and what must it do?
A Policy Enforcement Point is any component that inspects traffic and enforces security policies at a network boundary defined under TIC 3.0. It can be a physical appliance, a cloud-native security service, or a software-defined function. The TIC 3.0 Security Capabilities Catalog defines over 20 security capabilities that PEPs must support, including traffic filtering, intrusion detection, data loss prevention, and logging. The critical implementation detail is that a PEP must inspect traffic at the required depth for the applicable use case. A next-generation firewall with default vendor configurations deployed as a PEP is a PEP in name. Whether it satisfies the inspection requirements depends on how it is configured, not what it is.
What are the TIC 3.0 use cases and why do they matter?
CISA published use case guidance documents that define how TIC 3.0 requirements apply in specific deployment scenarios: traditional on-premises, cloud, remote users, and agency branch locations. Each use case specifies which security capabilities are required, how PEPs should be positioned, and what telemetry must be collected. The use cases matter because they translate the abstract Security Capabilities Catalog into specific implementation requirements for each deployment type. An agency that implements TIC 3.0 against the general catalog without working through the applicable use cases may satisfy the documentation requirement while missing use-case-specific controls that apply to their actual architecture.
What are the most common TIC 3.0 implementation failures?
Based on Vulnox assessments, the most consistent failures are: PEP configurations that allow CONNECT method requests to non-standard ports, bypassing content inspection for traffic tunneled through those connections; telemetry that produces logs at the event level but not at the session and content level required for incident investigation; application whitelisting that relies on vendor default policy categories rather than organization-specific approved application lists; and cloud use case implementations where security capabilities are distributed across multiple cloud-native services without centralized correlation, making incident detection functionally impossible.
How does TIC 3.0 apply to cloud environments?
The CISA cloud use case guidance defines how TIC 3.0 security capabilities apply when agency data and applications reside in cloud environments. Rather than routing cloud traffic back through a TICAP, agencies can implement cloud-native security controls as PEPs — cloud access security brokers, cloud security posture management tools, and cloud-native firewall services — provided those controls satisfy the Security Capabilities Catalog requirements for the applicable functions. The gap in most cloud implementations is that agencies deploy cloud security tools that satisfy some capabilities and leave others unaddressed, without mapping their deployment against the full capability set the use case requires.
What does TIC 3.0 require for logging and telemetry?
The TIC 3.0 Security Capabilities Catalog includes Telemetry and Logging Event Management as a required capability. The requirement covers collection of network flow data, security event logs, and application-layer transaction records at PEPs. Logs must be retained for a period sufficient to support incident investigation. The specific gap in most implementations is log normalization: agencies collect logs from multiple PEPs in different formats, and without normalization and correlation, the logs cannot be used to reconstruct a cross-environment attack path. Individual PEP logs exist. The ability to correlate them into an incident timeline does not.
Do commercial cloud services like AWS or Azure satisfy TIC 3.0 requirements?
Cloud provider security services can satisfy specific TIC 3.0 capabilities when properly configured. AWS GuardDuty can satisfy intrusion detection requirements. Azure Firewall can satisfy traffic filtering requirements. The key word is configured — provider services deployed with default settings do not automatically satisfy TIC 3.0 capability requirements. Additionally, no single cloud provider service satisfies the full Security Capabilities Catalog. Agencies must map their cloud security tool set against the applicable use case requirements and identify which capabilities each tool addresses, which are partially addressed, and which are unaddressed. That mapping exercise is what most cloud TIC 3.0 implementations skip.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.