The four default roles
Every ThreatAware tenant ships with four built-in roles. These are visible at Settings → Roles marked as Default Roles (“These are roles provided by default in the ThreatAware platform. Default roles cannot be edited”).
Default roles cannot be edited. To customise permissions, click + Create Role and define a new role from scratch.
Custom roles
The + Create Role flow at Settings → Roles lets you define a role with granular permissions across these axes:
Custom roles often map to organisational structure:
- “MSP Technician — Client Acme” — view devices only with
tags:Acme, no settings access - “Desktop Engineer — EMEA” — view EMEA devices, create Actions, no integration config
- “External Auditor” — view all device counts + compliance reports, no Personally Identifiable Information (PII) fields, no exports for 60 days
Teams
Settings → Teams defines logical groups for collaboration and sharing.
What Teams enable
- Saved view sharing: when you save a view, “Team” visibility lets you pick one or more teams
- Action ownership: Actions can be assigned to a team rather than an individual
- Studio app sharing: apps published to a team are visible only to that team
- Notifications routing: alerts route to the team’s nominated channel
SSO and SCIM
New in 3.3 Admins now set up single sign-on themselves for Microsoft Entra ID (Azure AD), Okta and CyberArk, and can provision users automatically with just-in-time or SCIM. See Single Sign-On and SCIM.Limit what a role can see
Each role’s Data Visibility decides which devices, users and network devices its members can see. It’s set on the role, at Settings → User Management → Roles, not in your identity provider, and it applies everywhere in ThreatAware: Devices, Issues, User Inventory, Software Inventory and Reporting.
For example, an MSP technician role with Device Visibility set to Selected tags: Client-Acme only ever sees Acme’s devices. The four default roles can see everything, so to restrict visibility, create a custom role.
Because visibility follows tags, it stays up to date on its own: a new device that joins the
Client-Acme tag is visible to that role straight away, with no permission change. Before you rely on a tag for access, check its counts in Settings → Tags, and use Debug in its Logic Engine flow to confirm the right devices match.
Visibility is by tag only. You can’t limit a role by location or another field directly, but you can build a tag that does, such as a UK tag from the device’s country, and use that. There’s no setting to hide individual fields.
API access
The ThreatAware API uses API keys managed at Settings → API Access. Keys are sent in theX-ThreatAware-ApiKey request header. Tokens:
- Have a name and a fixed expiration of 1 day / 1 week / 1 month / Never (no custom-date option)
- Are shown once at creation — copy and store securely
- Inherit the permissions of the user that created them
- Hover the row to reveal Disable key (suspends without deleting) or Delete key (terminal, after a Confirm dialog)
Audit Log
Every meaningful action is logged at Settings → Audit Log:Filtering the audit log
The audit log has a plain-text search box at the top of the grid (it is not the field-based query language used on Devices / Issues / Users). For more structured filtering, export and filter externally — or use the API. See Settings → Audit Log for column-level details.SIEM integration
For SIEM ingest, the recommended path is to pull from the API. Webhook and scheduled-export options may also be available depending on tenant configuration — confirm with your account team.Session management
Multiple concurrent sessions are allowed. For Entra ID SSO tenants, conditional access policies on the Microsoft side (including device-trust, location, and risk-based controls, plus session-lifetime caps) apply on top of any ThreatAware-side timeouts.MFA enforcement
ThreatAware does not surface tenant-side MFA enforcement controls in the current product. MFA is delegated to the upstream identity provider:- Entra ID / Azure AD SSO — enforce MFA in your Entra ID Conditional Access policies. ThreatAware honours whatever Entra returns.
- Okta SSO — enforce MFA in your Okta sign-on policy.
- CyberArk SSO — enforce MFA in your CyberArk Identity authentication profile.
- Password sign-in (non-SSO tenants) — the Roles permission tree was inspected and contains no MFA-related permission, idle timeout, IP restriction, or device-trust toggle. Use SSO as the recommended MFA path.
Best practices
Start with least privilege
Start with least privilege
Default new users to Limited Viewer or a tight custom role. Upgrade explicitly when need is demonstrated.
Quarterly access reviews
Quarterly access reviews
Review Settings → Users for the “Never logged in” / “Last logged in N days ago” badges and deactivate dormant accounts.
Service accounts for automation
Service accounts for automation
Don’t use a person’s API token for production automation. Create a dedicated service-account user with a narrow role and a long-lived API token, and document the owner.
Audit-log critical changes
Audit-log critical changes
Set up an Action that emails security leadership whenever the audit log shows role creation, integration disconnect, or large export.
Document the role matrix
Document the role matrix
Maintain a simple table: role × permission × who-it’s-for. Review annually.
Cross-references
SSO & SCIM
Single sign-on and user provisioning
Settings → Users
User list and SSO state
Settings → Roles
Default + custom roles
Settings → Teams
Collaboration groups
Settings → API Access
Token management
Settings → Audit Log
Activity history
Reference → Role permissions
Full permission matrix