How to Enable and Test Threat Intelligence Policies in Microsoft Entra Global Secure Access

Threats on the open internet change fast. You don’t want users wandering into phishing kits, malware droppers, or C2 infrastructure. Global Secure Access (GSA) Threat intelligence (preview) adds a safety net: it blocks access to high-severity, known-bad destinations using Microsoft and third-party intel feeds. You wire it up once, scope it with Conditional Access, and watch blocked hits roll into your traffic logs.

I’ll walk through prerequisites, setup, testing, and a few gotchas I’ve learned to avoid.

What you’ll need (5-minute checklist)

• Roles: Global Secure Access Administrator for GSA tasks; Conditional Access Administrator to bind the policy to users.
• Licensing: GSA lives under Microsoft Entra Internet Access (part of the Entra Suite or standalone). You also need Entra ID P1/P2.
• Client: Global Secure Access desktop client installed on the test device(s).
• Traffic acquisition basics:
• Disable Secure DNS/DoH on endpoints and browsers or align it to your forwarding rules (DoH can bypass acquisition).
• Prefer IPv4 and block QUIC (UDP/443) to avoid HTTPS bypass via HTTP/3:
• TLS inspection is optional but needed if you want URL indicators evaluated over HTTPS (without it, you match on domains). Ref: TLS Inspection in Microsoft Entra GSA Internet Access – Complete Configuration Guide

Heads-up: New security profiles can take 60–90 minutes to apply because enforcement rides on access tokens. Traffic logs can take a few minutes to show up. Plan testing time accordingly. 

More details refer my previous blog How to Configure Microsoft Entra Global Secure Access Internet Access with Web Filtering Policies

The setup at a glance

1. Turn on Internet traffic forwarding
2. Create the Threat intelligence policy
3. (Optional) Add an allow list rule for known business exceptions
4. Link it into a Security profile (or use the baseline profile)
5. Deliver it with Conditional Access

Step 1 Enable Internet traffic forwarding

In the Microsoft Entra admin center, go to Global Secure Access → Connect → Traffic forwarding → Internet access.
Enable it and scope to a pilot group first (use a small test group).
Confirm the GSA client shows the Internet profile is active on the test device.

Refer my previous blog for detailed configuration How to Configure Microsoft Entra Global Secure Access Internet Access with Web Filtering Policies 

Step 2 Create the Threat intelligence policy

Go to Global Secure Access → Secure → Threat intelligence policies → Create policy.

Name it clearly (e.g., TI-Block-High Severity), add a short description

Policy Settings Default Action will be Allow

Review the Settings and Choose create

By default, the engine includes a rule that blocks destinations with “high severity” threats (malware distribution, phishing, C2, etc.) based on Microsoft + third-party feeds.

Step 3 (Optional) Add an allow list rule

If you have a business site that’s mis-flagged, add an allow rule:
Open your Threat intelligence policy → Rules → Add rule.

Give it a name, set priority above the default block, set Action = Allow.
Add Destination FQDNs (comma-separated). Be thoughtful—allowing means accepting risk if the site later turns bad.

Step 4 Put it in a Security profile (or the Baseline)

A Security profile is the wrapper that groups GSA controls (TLS inspection, web filtering, threat intelligence, etc.). You can attach one TI policy per profile. Control order matters when multiple controls apply:

TLS inspection → 2) Web content filtering → 3) Threat intelligence → 4) File type → 5) DLP → 6) Third-party.

Create it:

Global Secure Access → Secure → Security profiles → Create profile.

We already have a Security Profile so we will use the same to attach our TI profile

Link → Existing threat intelligence policy → pick the one you created.

Save.

Shortcut: if you want tenant-wide coverage later, you can link TI to the Baseline profile (applies to all users’ traffic). Start with a pilot first.

Step 5 Deliver with Conditional Access

Threat intelligence becomes user/context-aware when you ship it through Conditional Access as a Session control:

Entra ID →  Conditional Access → New policy.
Assign your pilot group.
Target resources → All internet resources with Global Secure Access.
Session → Use Global Secure Access security profile → select your profile.

Enable = On → Create.

Enforcement of a new security profile can take 60–90 minutes to propagate. 

We already configured the CA policy so will use the same for Testing. My  Blog How to Configure Microsoft Entra Global Secure Access Internet Access with Web Filtering Policies includes the CA policy creation steps

(Optional) Turn on TLS inspection before testing URLs

If you want the engine to evaluate URL indicators (not just domains) inside HTTPS, enable TLS inspection and deploy the trusted root cert to devices (Intune makes this easy). Do this in a lab/pilot first and validate certificates in the browse

Refer my Blog TLS Inspection in Microsoft Entra GSA Internet Access – Complete Configuration Guide for more details

Test the policy

On a Windows device with the GSA client:
Confirm the Internet forwarding profile is active in the client diagnostics.

Browse to a known test site (e.g., entratestthreat.com or smartscreentestratings2.net). 

You should see a block and later find entries in Traffic logs with a Threat Type. (If SmartScreen blocks first, allow once just to confirm the GSA block page.) .Logs can take up to 5 minutes to show.

Want to see the types of threats being labeled? Microsoft lists them (Botnet, C2, Phishing, Malware, etc.)refer Global Secure Access Threat intelligence threat types  

Troubleshooting cheat sheet

1. Nothing is blocked: 

•  Is the CA policy assigned to the right users and enabled?
•  Did you select “All internet resources with Global Secure Access” and the Session control? 

2. Client seems to bypass:

• Check DoH/secure DNS in OS and browsers.
• Block QUIC (UDP/443); confirm browser falls back to TCP

3. HTTPS URLs aren’t matched:

• Turn on TLS inspection and deploy the root cert to devices.

4. I don’t see logs:

• Give it up to 5 minutes. Verify Diagnostic settings if exporting to LAW.

5. False positive:

• Add a narrow allow rule for that FQDN and report it as a false positive per Microsoft’s process.

Wrap-up

That’s it., you’ve connected traffic, turned on Threat intelligence (preview), delivered it with Conditional Access, and tested it end-to-end. Keep an eye on Traffic logs to understand which threats you’re stopping and where users need coaching. When your pilot looks good, scale the assignment, either by expanding your CA scope or moving the TI policy into the Baseline security profile for broad coverage