SafeToOpen Browser Security
MSP Operations: Overview, Linked Organisations and Administrator Access
One screen across every organisation you administer, MSP-wide blocking, and administrator rights that follow your identity provider
An MSP administers several SafeToOpen organisations, usually one per client. Three console features make that manageable: an overview across all of them, links between organisations so a confirmed threat is blocked everywhere at once, and administrator access that follows a group in your own identity provider so staff who leave lose access without anyone remembering to remove them.
1. MSP overview#
Browser Security console → Organisation → MSP overview. It lists every organisation where your account is an owner or co-admin, for both products, read-only.
| Column | Browser Security | Email Security |
|---|---|---|
| Seats | Used (members plus the owner) against the plan; red when over | Plus and Executive seats used against the plan |
| Open (30d) | Incidents still open from the last 30 days | Same |
| Last incident | Date of the newest incident | Same |
| Feeds | Threat feeds configured, with the URLs they have blocked | — |
| Connectors | Response connectors, with how many are untested | Response connectors |
| Rules | Live and dry-run response rules | Same |
| Actions (7d) | Response actions run in the last 7 days | — |
| Devices | Devices enrolled unattended through MDM | — |
| Health | Healthy, or flags: plan expired, critical incidents open, feed errors, connector errors, failed actions, over seats | Same, without feeds and actions |
Your own console’s organisation is marked “this console”; others show whether they are linked (section 2). The screen does not switch the console between organisations: every page of the console works on the organisation your account belongs to, so acting on another organisation means signing in as an administrator of that one.
2. Linked organisations and MSP-wide blocking#
- Browser Security console → Organisation → Response actions → Linked organisations. Every organisation where you are an owner or co-admin is listed; click Link. Linking is mutual and needs admin rights in both, which is what keeps it safe.
- Add the built-in connector “SafeToOpen blocked list (all workspaces)”; it needs no credentials.
- Add a rule: on Confirm, severity high, action “Block the URL in every workspace (and linked organisations)”, scope “This organisation and every linked organisation”. Start in dry run.
When an analyst confirms an incident, the URL goes onto each linked organisation’s own Block/Unblock list, which the extension enforces in every workspace within minutes. The action log names each organisation; Undo removes the URL from all of them. Manual entries on those lists are never touched.
3. Administrator access through your identity provider#
Settings → Administrator access, on both consoles, for the plan owner. Two switches, usable separately.
3a. Co-admins that follow a group#
- Connect the directory first: Microsoft 365 for Browser Security; Microsoft 365 or Google Workspace for Email Security (the same connection used to import people).
- Choose the connection and the group whose members should be co-admins, for example “SafeToOpen Admins”, then Use this group. The first sync runs at once and hourly afterwards, with the directory sync; Sync now forces one.
- Members of the group become co-admins; people who leave the group lose access at the next sync and their console sessions are ended. Co-admins added by hand are never removed by the sync.
| Rule | Effect |
|---|---|
| Account required | A group member with no SafeToOpen account yet is listed as skipped until they sign in once with Microsoft or Google. |
| Browser Security membership | Browser Security co-admins must be active members of the organisation; others are listed as skipped. |
| Limits | Browser Security allows 3 co-admins, Email Security 25; the sync stops at the limit and reports it. |
| Owner | The owner is never added or removed by the sync. |
3b. Require SSO for administrators#
Turning on “Require administrators to sign in with Microsoft or Google” refuses password sign-in for the organisation’s owner and co-admins with a message pointing at the sign-in buttons. Access then ends when the identity-provider account does. The console will not enable it until your own account has a Microsoft or Google sign-in linked, so you cannot lock yourself out. It applies to the console only; add-in and extension users are unaffected.