Guardrails for the Internet Lane: Rolling Out GSA Threat Intelligence

Not every suspicious click comes from a hoodie wearing hacker in a dimly lit basement. Sometimes it’s Anne in HR hunting for a fabric-softener discount. She’s not malicious she’s thrifty. However, those “great deals” can lead straight to trouble if clicking on the wrong link.

Enter Global Secure Access (GSA) Threat Intelligence. It taps into real-time threat data from Microsoft and trusted third-party sources to keep users away from known malicious destinations automatically. In this guide, we’ll walk through the setup, step by step. By the end, you’ll have a policy that quietly blocks the bad stuff while your users carry on with their day.

Prerequisites

Before we dive in, make sure you have:

The right roles. You’ll need Global Secure Access Administrator for GSA and Conditional Access Administrator for CA policies.
Licensing. Microsoft Entra Internet Access (part of GSA) is required. A Entra Suite trial works too.
GSA basics. Complete the initial GSA setup and install the GSA client on your test devices so traffic can be inspected.
Secure DNS disabled. Turn off DNS over HTTPS (DoH) on clients and any built-in resolvers in Edge/Chrome; GSA must tunnel DNS queries.
Network tweaks (preview caveats). Since the preview doesn’t capture IPv6, set adapters to prefer IPv4. Additionally, block outbound UDP 443 during the preview.

Once those boxes are checked, we’re ready to roll.

Step 1: Enable the Internet Access Traffic Forwarding Profile

Firstly, we need to route internet traffic through GSA so the threat-intel bouncer can actually check IDs at the door.

In Microsoft Entra admin center, go to Global Secure Access > Connect > Traffic forwarding.
Enable the Internet Access profile. This sends internet-bound traffic from devices with the GSA client to Microsoft’s Security Service Edge for inspection.
Scope it. Optionally assign to specific users/groups under User and group assignments. Otherwise, apply to everyone (great for labs/demos).
Save and give it a little time 10-15 minutes is a solid “Microsoft minute.”

I cover these steps in a bit more detail in a previous blog post.

Step 2: Create a Threat Intelligence Policy

Now that traffic is flowing, let’s add the brains: a policy that blocks destinations flagged as high-severity threats. Think of malware hosts, phishing domains, and C2 infrastructure.

Go to Global Secure Access > Secure > Threat Intelligence policies.
Click + Create policy.
Name it (e.g., “Block Malicious Sites”) and add a description if you like.

Note the Default action: Allow. In other words, anything not explicitly deemed malicious by the feeds is allowed.

Review and Create.

Consequently, your new policy will automatically block access to sites Microsoft (and partners) identify as seriously risky, in real time.

Step 3: (Optional) Configure an Allow List for Safe Exceptions

Sometimes, threat intelligence feeds might flag a site that you know is safe or business-critical. In those cases, you might need to let that site through despite the threat intelligence saying “block it.” This is where an allow list (or exception list) comes in. Use this sparingly! Allowing a site means you’re bypassing the protection for that domain, so only do this for sites you trust and really need.

Go back to Global Secure Access > Secure > Threat Intelligence Policies, and click on the threat intelligence policy you created earlier (e.g., “Block Malicious Sites”).
In the policy details, find and select the Rules tab or section. This is where individual allow, or block rules live under the policy.
Click Add rule to create a new exception/allow rule. A form will appear for rule details.
Give the rule a Name (e.g., “Allow Shady Site”), and a Description if desired. Set a Priority order for the rule. The priority determines the order in which rules are evaluated. A lower number might mean the rule is evaluated earlier. Ensure the rule Status is enabled/On.
Under Destination FQDNs, list the domain(s) to allow (comma-separated).
Click Add to create the allow rule and add it to the policy’s rule list. The new rule should now appear alongside the default blocking rule.

I cannot stress this enough, you’re essentially punching a hole (even if a tiny, well-intentioned one) in your security net. Review your allow list periodically; today’s “trusted” site can be tomorrow’s compromised one.

Step 4: Create a Security Profile for Your Policies

Next, we’ll package your threat-intel policy into a Security profile. A neat container you can later apply via Conditional Access.

Here’s how to create a security profile and link your Threat Intelligence policy to it:

Back in Entra, navigate to Global Secure Access > Secure > Security profiles.
Click Create profile to make a new security profile.

Click Create profile and give it a friendly name (e.g., “Internet Threat Protection Profile”), a description, set it Enabled, and assign a priority (lower = higher precedence).

Link the Threat Intel Policy: In the profile setup, you should see an option to Link a policy. Choose Existing threat intelligence policy. A list or dropdown will appear; select the Threat Intelligence policy you made earlier. Then click Next.

Optionally, add other policy types (e.g., web content filtering) to the same profile.
Review the profile and make sure your threat intel policy is listed as included. Then click Create profile to finalize it.

Note: you can only add one threat-intel policy per profile, but you can combine it with other policy types. There’s also a Baseline profile that applies globally, but a custom profile gives you better control, especially for pilots.

Step 5: Link the Security Profile to a Conditional Access Policy

Now we have a security profile that contains our threat filtering policy, but we need to deliver that profile to users. In Microsoft Entra, Conditional Access (CA) is the magic glue that applies policies to user sessions. We’ll create a Conditional Access policy that says, essentially, “when users access the internet, apply our shiny new security profile.”

Don’t worry if you’re not a Conditional Access ninja this will be relatively painless:

In Entra, go to Entra ID > Conditional Access (or just search at the top).
Click Create New Policy.
Give it a clear name like “Apply GSA Threat Intelligence to Internet Access”. This will help you identify it later among your other CA policies. (Side note: Be sure to have a proper naming convention for your policies. This will help you SO MUCH in the future. You’ll thank me later.)
Under Assignments, choose Users or workload identities and select the users or groups that this policy will apply to. Typically, you’d match this with the same scope as your traffic forwarding profile. For example, if you enabled Internet Access forwarding for all users or a test group, select those same users/groups here.
In the Target Resources section, you need to specify that this policy applies to internet traffic via GSA. Choose All Internet Resources. Essentially, we’re telling the CA policy “apply when the user is accessing internet content through the GSA service.”
Under Session controls, enable Use Global Secure Access security profile and pick the profile you created.

Create the policy and make sure it’s set to On (or Report-only if you’re just testing, but On is needed to enforce).

Your Conditional Access policy is now in place, which means the Threat Intelligence filtering profile will be applied whenever the specified users access internet resources through GSA. Essentially, as users browse the web, the CA policy ensures the threat intelligence rules are evaluated on that traffic.

Important: Applying a new security profile via Conditional Access is not instantaneous. It can take up to 60-90 minutes for the policy to fully propagate and be enforced. Give it time, and do not panic if you do not see if right away.

Step 6: Verify that Threat Intelligence is Working (Testing Time!)

Now, let’s confirm the guard is on duty.

Check the GSA client. On a scoped device, open the GSA client > Advanced diagnostics (admin required) and verify Internet Access forwarding rules are active.
Visit a safe test URL. Try entratestthreat.com or smartscreentestratings2.net. They’re designed to trigger security systems. You should see a block (browser error or a GSA message), and the attempt should show up in Traffic logs with a threat category.
Open a web browser and navigate to a known test malicious site. Microsoft provides some safe test URLs like entratestthreat.com or smartscreentestratings2.net which are designed to be flagged by security systems. Attempt to visit one of those. The page should be blocked you might see a browser error or a GSA block message indicating the site is not reachable. In the Entra admin center’s Traffic logs, the attempt should be logged with a threat category.

Heads-up about SmartScreen. If Microsoft Defender SmartScreen blocks first, you may need to (carefully) bypass it for test purposes so GSA can inspect the traffic. Obviously, don’t make a habit of bypassing SmartScreen. It’s there for a reason.

Caution: Stick to known test sites or a sandbox. Please don’t go searching for real malware “just to see.”

Wrapping Up

All in all, you’ve:

Enabled Internet Access traffic forwarding,
Created a Threat Intelligence policy,
(Optionally) added a careful allow list,
Packaged it into a Security profile, and
Applied it via Conditional Access, then verified it works.

As a result, your users gain a constantly updated, behind-the-scenes bodyguard that blocks phishing and malware hosts before they ever load in the browser. Moreover, because it’s cloud-intelligent, it improves continuously no manual feed wrangling required.

One last note: this feature is in preview (as of September 2025). Features may change, so keep an eye on updates and refine your configuration accordingly. In the meantime, Anne still gets her fabric softener just not from a dodgy domain.