Response Actions: Blocklist, Microsoft 365, Entra ID, Defender, Okta, EDR, Web Gateways, Paging, Chat and MSP Propagation

Response actions turn a SafeToOpen incident into a change in the systems you already run. You connect a system once, then write rules: which incidents, at which severity, trigger which action, either the moment the incident arrives or when an analyst marks it a confirmed issue. Every action is logged with its trigger and result; most can be undone from the log or from the incident. The feature exists in both consoles: Browser Security (Configuration → Response actions) and Email Security (Organisation → Response actions), each with its own connectors and rules.

This guide is organised by integration. Each one has the same four parts: what it gives you, what you need before you start, how to connect it, and the actions it adds with their scope and whether they can be undone. Section 2 is a single table of everything, if you only want the overview.

1. Concepts#

The same action never runs twice for the same incident, so an automatic rule and a Confirm rule on the same action do not double up. The one exception is the chat card, which may post once per trigger so the channel sees both the alert and the confirmation.

2. What each integration lets you do#

Four kinds of outcome are available. Blocking a URL or domain stops everyone in the organisation from reaching the page, on devices with or without the extension, depending on the system. Containing the user ends the sessions and forces a password change for the person who visited the page or reported the message. Stopping the sender keeps the same attacker out of every other mailbox. Alerting and paging bring a person into the loop. The table lists which integration delivers which outcome, in which console, and whether the action can be reversed from SafeToOpen.

“Browser” means the action is offered on Browser Security incidents, “Email” on Email Security incidents, “Both” on either. Sender actions are described in full in the Email Security response guide; this guide covers everything offered on Browser Security incidents.

Which to use for what#

3. Hosted blocklist#

What it gives you#

SafeToOpen publishes the organisation’s confirmed URLs and domains as a plain-text list at a token-protected address. Any firewall or gateway that pulls external lists reads it on its own schedule, so a confirmed incident is blocked at the network edge for every device, with nothing to install and no vendor API to connect. Optionally the same list also carries the URLs your threat feeds blocked and the URLs you blocked by hand, so the firewall enforces everything the extension enforces.

Before you start#

• A firewall or gateway that supports external dynamic lists, and a refresh interval of five minutes or more.
• Outbound HTTPS from the device to plus.safetoopen.com.

Set-up#

1. Response actions → ＋ Hosted blocklist. Tick “include threat-feed URLs” and “include manually blocked URLs” if the firewall should carry those too.
2. Copy the address. Append ?format= for the shape your device expects: urls (default, one full URL per line), domains, panos-url (no scheme), panos-domain, json, csv.
3. Add rules: “Add the URL to the hosted blocklist” and “Add the domain to the hosted blocklist”, on Confirm at severity high, in dry run first.
4. Point the device at the list and refresh every 5 minutes or longer; the address returns an ETag so unchanged lists cost nothing.

Actions#

4. Microsoft 365 and Entra ID#

What it gives you#

One connector, one Entra app registration, and you can act on three layers of a Microsoft 365 tenant. On the web layer, a confirmed URL goes onto the Tenant Allow/Block List, so Outlook, Defender for Office 365 and Defender SmartScreen block it for every mailbox and device in the tenant, not only those with the extension. On the identity layer, you can make a stolen password useless within seconds of a credential-phishing incident: sign the person out of every app and browser, require a new password at the next sign-in, and mark the account as compromised so your risk-based Conditional Access policies (block, MFA, password reset) apply automatically. On the mail layer, used by Email Security incidents, you can block the sender for the whole tenant and junk their mail in members’ mailboxes. Add the Defender for Endpoint permission (section 5) and the same connector also blocks the domain on every onboarded device.

Before you start#

• A Global Administrator or Application Administrator to create the app registration and grant admin consent.
• For the password-change action, someone who can assign the app the User Administrator role in Entra.
• For the compromised-user action, Entra ID P2 (Identity Protection) and at least one risk-based Conditional Access policy, otherwise the flag is recorded but nothing enforces it.

Set-up#

1. Entra admin center → Identity → Applications → App registrations → New registration. Name it (for example “SafeToOpen response actions”), leave “Accounts in this organizational directory only”, no redirect URI, Register.
2. On the app’s Overview page copy the Application (client) ID and the Directory (tenant) ID.
3. Certificates & secrets → Client secrets → New client secret → choose an expiry (set a reminder; the connector stops working when it expires) → Add. Copy the Value column now; it is shown once.
4. API permissions → Add a permission → Microsoft Graph → Application permissions. Add only what the actions you want need (table below), then Grant admin consent for the tenant. The Status column must show a green tick on every row.
5. Only if you want the password-change action: Identity → Roles & admins → User Administrator → Add assignments → search for the app by name → Add. Without the role the action fails with a clear message.
6. SafeToOpen console → Response actions → ＋ Microsoft 365 and Entra ID → tenant ID, client ID, secret → Add connector → Test. The test signs in and lists which of the permissions the token carries and which are missing.

Actions#

Rules to add#

• On Confirm, severity high: Block the URL for the whole tenant.
• On Confirm, kinds containing “credential” or “password”: Sign out everywhere, then Require a password change. Add Mark as compromised if you run Identity Protection.
• Leave the identity actions on Confirm rather than automatic; a false positive that signs out an executive costs more than the minute an analyst takes to confirm.

5. Defender for Endpoint#

What it gives you#

A hard block on every device onboarded to Defender for Endpoint, whether or not the device runs the SafeToOpen extension and whether it is in the office, at home or on a hotel network. The action creates a custom network indicator: Defender’s network protection blocks connections to the domain or URL in every browser and every application, shows the user a Windows block notification, and raises an alert in the Defender portal each time a device tries to reach it, which tells you who else clicked the link. You choose a domain indicator (covers every path and subdomain page on that host) or an exact URL indicator (only that address, useful when the host is a shared platform such as a form builder or a file share). Indicators expire after 90 days.

Before you start#

• Devices onboarded to Defender for Endpoint (plan 1 or 2), with network protection turned on in block mode. Without network protection, Edge still honours the indicator through SmartScreen but other browsers do not.
• Custom network indicators enabled: Defender portal → Settings → Endpoints → Advanced features → Custom network indicators: On.
• The Microsoft 365 connector from section 4.

Set-up#

1. Entra admin center → the app registration from section 4 → API permissions → Add a permission → APIs my organization uses → search “WindowsDefenderATP” → Application permissions → Ti.ReadWrite.All → Add → Grant admin consent.
2. SafeToOpen console → Response actions → the Microsoft connector → Test. The result now lists the Defender permission as present.
3. Add a rule: on Confirm, severity high, action “Block the URL or domain on every device”, option Domain indicator. Dry run first; the log shows the exact indicator that would be created.

Actions#

6. SafeToOpen blocked list and MSP propagation#

What it gives you#

The built-in connector needs no credentials. Its action adds the confirmed URL to your own Block/Unblock URLs list, which the extension enforces in every workspace of the organisation within minutes, on every platform the extension runs on. For managed service providers, scope “linked organisations” adds the same URL to every organisation linked to yours in one action, so one client’s confirmed phishing page is blocked for all the clients you manage before the campaign reaches them.

Set-up#

1. Response actions → ＋ SafeToOpen blocked list (all workspaces). Nothing to enter.
2. MSPs: Response actions → Linked organisations. Every organisation where you are an owner or co-admin is listed; click Link. Linking is mutual and requires admin rights in both, which is what makes the propagation safe.
3. Add a rule: on Confirm, severity high, action “Block the URL in every workspace (and linked organisations)”, scope “This organisation and every linked organisation”.

7. Web gateways and DNS filters#

Each of the following is its own connector with its own credentials. They block for everyone behind the gateway, including devices without the extension, and are the right first choice for a hard organisation-wide block. All act on Browser Security incidents, start in dry run like any rule, and can be undone.

Cisco Umbrella#

What it gives you#

A DNS-layer block, and a proxy block where Umbrella’s intelligent proxy is on, for every network and roaming client that uses a policy containing the integration’s destination list. Blocking at DNS means the page cannot load in any browser or application, and Umbrella’s reports show which identities tried.

Set-up#

1. Umbrella dashboard → Policies → Policy Components → Integrations → Add. Name it “SafeToOpen”, tick Enable, Save. Expand the row and copy the customer key from the integration URL (the long value after /integrations/).
2. Umbrella creates a destination list with the integration’s name. Policies → Management → All Policies → open each policy that should enforce it → Destination Lists → add the integration list under Block.
3. SafeToOpen console → ＋ Cisco Umbrella → paste the key → Add connector → Test.

Zscaler Internet Access#

What it gives you#

A URL block for every user whose traffic passes through ZIA, by adding the URL to a custom category that a URL Filtering rule blocks. The change is activated immediately, so it applies within about a minute rather than waiting for an admin to activate pending changes.

Set-up#

1. ZIA admin portal → Administration → API Key Management → Cloud Service API Key → note or create the key. You also need an admin account with API access enabled (Administration → Administrator Management → the admin → Enable API access), and to know your cloud name from the portal address (zscaler.net, zscalerone.net, zscalertwo.net, zscalerthree.net, zscloud.net or zscalerbeta.net).
2. Administration → URL Categories → Add URL Category → name it “SafeToOpen Blocklist”, type Custom, Save and Activate. Note its id from the row or the browser address (CUSTOM_nn).
3. Policy → URL & Cloud App Control → Add URL Filtering Rule → URL Categories: the new category → Action: Block → Save and Activate.
4. SafeToOpen console → ＋ Zscaler Internet Access → cloud, admin username, password, API key, category id → Add connector → Test.

Netskope#

What it gives you#

A URL block for every user steered through Netskope, by appending the URL to a URL list that a Real-time Protection policy blocks, then deploying the list. Because the list is exact-match you can block a single page on a shared host without affecting the rest of the site.

Set-up#

1. Netskope tenant → Settings → Tools → REST API v2 → New Token → name it, choose an expiry, and add the endpoints /api/v2/policy/urllist and /api/v2/policy/urllist/deploy with Read and Write. Copy the token.
2. Policies → Profiles → URL Lists → New URL List → name “SafeToOpen Blocklist”, type Exact, add any placeholder entry, Save, then Apply Changes.
3. Policies → Real-time Protection → New Policy → Web Access → Destination: the URL list → Action: Block → Save and Apply Changes.
4. SafeToOpen console → ＋ Netskope → tenant host (yourtenant.goskope.com), token, list name → Add connector → Test.

Cloudflare Zero Trust#

What it gives you#

A block for every device or network using Cloudflare Gateway, at the DNS layer with a domain list or at the HTTP layer with a URL list. Choose the list type when you create it: a DOMAIN list blocks the whole host in DNS and HTTP policies, a URL list blocks the exact address in HTTP policies.

Set-up#

1. Cloudflare dashboard → My Profile → API Tokens → Create Token → Custom token → Permissions: Account → Zero Trust → Edit → the account → Create. Copy the token. Note the account id from Zero Trust → Settings or the dashboard address.
2. Zero Trust → My Team → Lists → Create manual list → type DOMAIN (for hosts) or URL (for exact addresses) → name “SafeToOpen Blocklist” → add a placeholder → Save. Copy the list id from its address.
3. Zero Trust → Gateway → Firewall policies → DNS (for a domain list) or HTTP (for either) → Add a policy → Selector Domain or URL → Operator “in list” → the list → Action Block → Create.
4. SafeToOpen console → ＋ Cloudflare Zero Trust → account id, token, list id → Add connector → Test. The test reports the list name and type.

8. Endpoint protection and XDR#

Endpoint tools reach devices wherever they are, but their treatment of domain indicators differs: Defender and Vision One block, CrowdStrike blocks or detects depending on the option and platform, SentinelOne and Sophos need a policy or rule of yours to turn a tag or indicator into a block. Pair them with a gateway action when you need a hard block everywhere.

CrowdStrike Falcon#

What it gives you#

A domain indicator of compromise applied to every host in the Falcon tenant. As Detect it raises a detection whenever a sensor sees a connection to the domain, so you learn who else went there; as Prevent it blocks the connection on platforms where the sensor supports domain blocking. Indicators expire after 90 days.

Set-up#

1. Falcon console → Support and resources → API clients and keys → Create API client → name it → scope IOC Management: Read and Write → Create. Copy the client id and secret; note the base URL shown (US-1, US-2, EU-1 or US-GOV-1).
2. SafeToOpen console → ＋ CrowdStrike Falcon → cloud, client id, secret → Add connector → Test.
3. Add a rule with the option Detect for the first weeks; switch to Prevent once you have seen how detections behave.

SentinelOne#

What it gives you#

A DNS threat-intelligence indicator on the account or site. SentinelOne agents detect connections to the domain and surface them as threats with the SafeToOpen incident as the source; blocking requires a STAR custom rule on your side that acts on those detections. Indicators expire after 90 days.

Set-up#

1. SentinelOne console → Settings → Users → Service Users → Create New Service User → scope to the account or site → role with Threat Intelligence: Create and Delete → Generate API token. Copy it, and note the account id or site id (Settings → Accounts or Sites).
2. SafeToOpen console → ＋ SentinelOne → console URL (https://yourtenant.sentinelone.net), token, scope → Add connector → Test.

Sophos Central#

What it gives you#

A domain block for every endpoint under a Threat Protection policy that blocks the tag you choose. The action adds the domain to Website Management with that tag; Web Control on each endpoint then blocks it, and Sophos reports the attempt.

Set-up#

1. Sophos Central → Global Settings → API Credentials Management → Add Credential → name it, role Endpoint Admin (or Service Principal Super Admin) → copy the client id and secret. Use the tenant’s own credentials, not a partner account.
2. Endpoint Protection → Policies → Threat Protection → your policy → Web Control → Website tagging → add the tag “SafeToOpen-Blocked” with action Block → Save.
3. SafeToOpen console → ＋ Sophos Central → client id, secret, tag → Add connector → Test.

Trend Micro Vision One#

What it gives you#

A Block suspicious object that every connected Trend product (Apex One, Cloud One, Deep Security, Email Security) enforces. Domain objects block the host, URL objects the exact address. Objects expire after 30 days.

Set-up#

1. Vision One console → Administration → API Keys → Add API Key → role with Threat Intelligence: Suspicious Object Management → Add. Copy the key and note your region from the console address.
2. SafeToOpen console → ＋ Trend Micro Vision One → region, key → Add connector → Test.

9. Mimecast#

What it gives you#

On Browser Security incidents, a Managed URL with action Block so URL Protect rewrites and blocks the link in every message that carries it, past and future. On Email Security incidents, the same connector blocks the sender for everyone through a Blocked Senders policy.

Set-up#

1. Mimecast Administration Console → Services → API and Platform Integrations → Your Application Integrations → Add API Application → API 2.0. Name it, choose the Managed URL (create, delete) and Blocked Senders Policy (create, delete) permissions → Save. Then Create Keys → copy the client id and secret.
2. SafeToOpen console → ＋ Mimecast → client id, secret → Add connector → Test.

10. Identity: Google Workspace and Okta#

Use these instead of, or as well as, the Entra ID identity actions depending on which system is the source of truth for sign-in. If Okta fronts Microsoft 365 or Google, act in Okta: signing out of Entra alone leaves the Okta session that can mint a new one.

Google Workspace#

What it gives you#

For the affected member: end every Google session on web and mobile, and force a password change at the next sign-in. On Email Security incidents the same connector also sends the sender’s mail to Spam with a Gmail filter.

Set-up#

1. Google Cloud console → IAM & Admin → Service Accounts → Create → then Keys → Add key → JSON. Keep the file.
2. Google Admin console → Security → Access and data control → API controls → Manage domain-wide delegation → Add new → the service account’s client id → scopes https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.user.security and, for the Spam filter, https://www.googleapis.com/auth/gmail.settings.basic → Authorise.
3. SafeToOpen console → ＋ Google Workspace → the admin account to act as (a super admin or a delegated admin with user management rights) and the JSON key pasted whole → Add connector → Test.

Okta#

What it gives you#

For the affected member, matched by email as the Okta login: clear every Okta session and revoke the OAuth tokens issued to the user, so every application behind Okta demands a fresh sign-in; expire the password so the next sign-in sets a new one; or suspend the account outright until an admin unsuspends it.

Set-up#

1. Okta Admin console → Security → API → Tokens → Create token. Create it from an admin who can manage the users concerned (Super Admin, or a custom admin role scoped to the right groups). Copy the token.
2. SafeToOpen console → ＋ Okta → org URL (https://yourcompany.okta.com) and the token → Add connector → Test.

11. Slack and Microsoft Teams incident cards#

What it gives you#

An incident card in the channel your team already watches, the moment a high-severity incident arrives: severity, kind, host, URL, user, workspace, time and the top reasons, with three buttons. Open incident goes to the incident detail. Confirm issue & respond marks the incident confirmed and runs your on-Confirm rules. No issue closes it. Incoming webhooks are one-way, so the buttons open the console signed in and act after one prompt; that is what puts the analyst’s name on the action instead of a shared bot. With an on-Confirm rule as well, the channel also sees who confirmed and what ran.

Slack set-up#

1. Open https://api.slack.com/apps → Create New App → From scratch → name it “SafeToOpen” → pick your workspace → Create App.
2. In the app’s left menu → Incoming Webhooks → switch Activate Incoming Webhooks to On.
3. Scroll down → Add New Webhook to Workspace → choose the SOC channel → Allow. Copy the Webhook URL (it starts with https://hooks.slack.com/services/).
4. SafeToOpen console → Response actions → ＋ Slack → paste the URL → Add connector → Test. A “SafeToOpen connected” card appears in the channel.

Microsoft Teams set-up#

Teams receives cards through a Workflows webhook (Power Automate, included with Microsoft 365). The older Office 365 Connectors “Incoming Webhook” has been retired by Microsoft; existing legacy URLs still work in the connector but new ones should be Workflows.

1. In Teams, open the channel that should receive cards → click the ⋯ next to the channel name → Workflows. (If you do not see Workflows, open the Workflows app from the left rail and choose Create.)
2. Search the templates for “webhook” and choose “Post to a channel when a webhook request is received”.
3. Give the flow a name such as “SafeToOpen incidents”, make sure it is signed in as you, click Next.
4. Choose the Team and the Channel the cards should post to → Add workflow.
5. The final screen shows the webhook URL (it starts with https://….logic.azure.com:443/workflows/… or https://….webhook.office.com/…). Copy it → Done.
6. SafeToOpen console → Response actions → ＋ Microsoft Teams → paste the URL → Add connector → Test. A “SafeToOpen connected” card appears in the channel, posted by the Workflows bot.

Rules#

1. Add a rule: connector Slack or Teams → action “Post an incident card” → Automatically when the incident arrives → minimum severity high (or critical for a quieter channel) → leave kinds blank → dry run off; a card is not a change you need to rehearse.
2. Optionally add a second rule on the same connector: On Confirm → any severity, so the channel sees the confirmation and the outcome of the on-Confirm rules.

12. PagerDuty and Opsgenie paging#

What it gives you#

A page to whoever is on call, with the incident facts and a console link, for incidents above the severity you choose. One PagerDuty incident or Opsgenie alert per SafeToOpen incident, severity mapped to their scales (critical → PagerDuty critical / Opsgenie P1, high → error / P2, medium → warning / P3). Undo resolves or closes the page, and marking the incident “no issue” in SafeToOpen resolves or closes it automatically, so the on-call is not left with a stale page.

PagerDuty set-up#

1. PagerDuty → Services → Service Directory → the service that should own these incidents → Integrations tab → Add an integration → Events API V2 → Add.
2. Open the new integration and copy the Integration Key (32 characters). Note whether your account is in the US or EU service region (EU accounts sign in at eu.pagerduty.com).
3. SafeToOpen console → Response actions → ＋ PagerDuty → region, integration key → Add connector → Test. The test sends a resolve for a key that does not exist, so nobody is paged.

Opsgenie set-up#

1. Opsgenie → Teams → the team → Integrations → Add integration → API → name it “SafeToOpen” → tick Create and Update Access and Read Access → Save integration. Copy the API key. Note whether the account is US or EU (EU accounts sign in at app.eu.opsgenie.com).
2. SafeToOpen console → ＋ Opsgenie → region, API key, responder team name (optional) → Add connector → Test.

Rules#

1. Add a rule: action “Page the on-call” → Automatically when the incident arrives → minimum severity critical → dry run off.
2. Keep the chat card at high and the page at critical, so people are woken up only for what warrants it.

13. Recommended rules#

Start every blocking and identity rule in dry run for a few days, read the log, then switch dry run off. Alert and paging rules can start live.

14. Working an incident#

Every incident detail ends with a Response panel. Before confirming, it lists what the Confirm rules would do, with the exact target each one would act on. It offers each available action as a button for a one-off manual run, and lists every action already taken on the incident with its result and an Undo where possible. Confirm issue runs the Confirm rules and reports their outcome in the same click. Buttons on a Slack or Teams card open the same panel.

15. Audit and safety#

• Actions appear in the Activity log and in the Response actions log with trigger, actor (analyst email, or auto-rule), target, the vendor’s response and the time.
• Rate limits: 120 manual actions per hour per organisation.
• Feed and manual entries in the hosted blocklist never leave the organisation; the blocklist token is the only credential and is rotatable.
• Connector secrets are encrypted at rest and never shown again. Microsoft Graph tokens are cached briefly and scoped to .default; every other vendor token is used only for the call and never logged.
• Every connector is built on the vendor’s published API. Vendor consoles change; if a Test or an action fails with a vendor error, the message quotes the vendor’s response so you can check the permission or object on their side.