Overview
Secureframe now gives you greater control over who is added to your Personnel list. With email domain filtering, you can ensure that only users from specific domains are synced into Secureframe through your HR and identity integrations.
This is especially useful if:
- Your organization manages multiple email domains (e.g., @secureframe.com, @acquiredcompany.com)
- You only want to track compliance for employees in a particular domain
- You need to prevent external or non-work accounts from being added automatically
How It Works
Secureframe has added domain filtering settings to Personnel settings. Only personnel with an email that matches the allowed domain(s) you’ve configured will be shown on the personnel page
- Applies globally – Domain filters apply across all integrations
- Flexible – You can allow one or multiple domains
- Automatic enforcement – Any personnel outside the approved domains will not be added
Video Tutorial
Setting Up Email Domain Filtering
- Navigate to Settings
- Go to Personnel Page > Click gear icon to access Personnel Settings > Email filtering
- Go to Personnel Page > Click gear icon to access Personnel Settings > Email filtering
- Enable Filtering
- Click on the + icon to add filter conditions
- Review the filter results in the table below that displays included and excluded results
- Save Changes
- Once saved, filtering applies automatically across all existing and future integrations
- Changes in the personnel page will be reflected after the next scheduled integration sync
Understanding the Personnel Table Columns
When reviewing personnel records synced from your vendor integrations, each column in the Included / Excluded tables provides additional user context:
| Column | What it Represents |
|---|---|
| Vendor name | The third-party system the user was imported from (e.g., Google Cloud, HubSpot, Slack, Gusto). A user may appear multiple times if they exist across multiple integrations. |
| The primary email address associated with that user in the vendor system. This is used for filtering and domain-based inclusion/exclusion rules. | |
| Name | The user’s display name as provided by the vendor application. Secureframe does not edit or assign these names. |
| Username | The login identifier stored in the vendor system (e.g., an ID, alias, or email). Not all vendors return a username, so this may appear as None. |
| Roles | ✅ Important: Role names come directly from the vendor application (e.g., Zoom, Slack, Google Cloud, Microsoft Entra ID) — not from Secureframe. These reflect the permissions assigned in the source system (e.g., owner, admin, full_member). Role values may vary based on vendor naming. |
| Active | Shows whether the user is still active in the external system. This can help identify stale or deprovisioned accounts. |
| Two-factor enabled | Indicates whether the user has MFA/2FA turned on in the vendor system. Available only if the integration supports sharing that attribute. |
Frequently Asked Questions (FAQ)
Can I change the domains later?
- Yes, you can edit the list anytime by updating filter conditions and saving those conditions. Changes will apply when future integration syncs run and results will be displayed accordingly.
Does this affect policy acceptance or UARs?
- Yes. Because only filtered personnel are included, your compliance workflows (policy assignments, reminders, access reviews) will only apply to the allowed domains.
Tip: Double-check that you include all valid domains for your workforce before saving, to avoid unintentionally excluding active employees.
Can I filter or exclude personnel by Entra ID (Azure AD) groups or licenses, and does Secureframe support true domain-level filtering?
- At this time, Secureframe supports global email domain filtering only, based on the email domain stored on personnel records (for example,
@company.com). This filtering is intentionally broad and works by matching the domain string on user email addresses. - Secureframe does not currently support filtering personnel by Entra ID (Azure AD) groups, licenses, or roles (such as Office 365 F3, E3 license groups, or internal role-based groups). Because of this, domain filtering cannot distinguish between different internal user types (for example, corporate users vs. operational or “club” staff) if they share the same email domain.
- If more granular personnel scoping is needed today, exclusions must be handled manually.
Comments
0 comments
Article is closed for comments.