US flag signifying that this is a United States Federal Government website An official website of the United States government

Meeting TIC requirements

Meeting TIC requirements

It is your responsibility to identify and comply with relevant Trusted Internet Connetions (TIC) requirements as guided by your agency. To help you with compliance, here’s guidance for interpreting the TIC reference architecture v2.0 as it concerns

Formal statement of customer responsibility

The System Security Plan has a formal description of customer responsibility under CA-3 (3).

Use-cases for accessing

The TIC reference architecture includes two use case examples on pages 63 and 64 that are relevant for federal agencies using Here we describe how to interpret those use cases in the context.

Restricting developer and operator access to services

You can ensure that developer and operator access to services traverses your agency’s TIC so that you can monitor all changes to your organizations, spaces, applications and services. The diagram below shows how the traffic flows.

graph TB subgraph Agency network A((Agency user)) TIC end subgraph boundary IPFilter[TIC IP filter] APIRouter subgraph Agency information system App end end subgraph Internet B((Agency user)) end A -->TIC TIC -->|"TLS (encrypted tunnel)"| IPFilter B -.->|"TLS (encrypted tunnel)"|IPFilter IPFilter --> APIRouter[ API] APIRouter -->|Change app| App

Figure 1. restricting changes to agency origin

Any traffic from an agency-authorized boundary (eg physical network of an agency building, or collective virtual boundary for all networked agency buildings) to one that it is not under your agency’s control (e.g. the open internet, or is likely already routed over a TIC connection.

For requests originating from your agency’s TIC egress bound for, our TLS implementation plays the role of the orange “encrypted tunnel” in Figure 14 of the TIC reference architecture. You will access both and exclusively over TLS because the domain is included in the HSTS preload list for your browser. (If you try to directly access those domains via HTTP, your request will be 301 redirected over to HTTPS; it’s not possible to get any other response without TLS.)’s TLS endpoint is not restricted, but rather accessible over the open internet. When an administrator wants to interact with the deployed application through the API, it’s your agency’s responsibility to make sure that traffic goes over a TIC connection before it reaches its destination on For example, you may not want users to be able to manipulate applications on from their home connection or via a wifi access point in the local coffee shop.

Your agency can accomplish this by establishing an operational requirement that all administrative access to services happens via the agency network. You can further enforce this requirement with a technical control: Prevent users in your domain from using the API except from your agency’s TIC egress range. Requests from an IP origin that does not match the range we have on record for your TIC (the dotted/dashed line in the diagram) will be rejected.

Restricting usage of your application

You may also need to restrict access through the “front door” of your deployed applications, such as administrator access to a Wordpress site, or public access to an internal-only service. The diagram below shows where you can implement this restriction.

graph TB subgraph Internet RUser((Agency user)) PUser((Public user)) end subgraph Agency network AUser((Agency user)) TIC VPN end subgraph boundary PRouter[App router] subgraph Agency information system RouteService App end end AUser -->TIC RUser -->|VPN|VPN[VPN endpoint] VPN --> TIC PUser -->|"TLS (encrypted tunnel)"| PRouter[App router] TIC -->|"TLS (encrypted tunnel)"| PRouter[App router] PRouter -->|Access app| RouteService RouteService[App logic or route service] --> App

Figure 2. restricting client access to your application

For remote workers or partners outside the normal agency network boundary, you can require use of a VPN to ensure that traffic is routed over the agency network and TIC (shown in Figure 15 of the TIC Reference architecture).

You can then reject requests to your app unless they come from your agency’s TIC egress range. You can do this by modifying your application logic or deploying a user-provided route-service to act as a proxy.