Skip to content

Roles & Permissions

Roles and permissions in Devici determine who can access the platform, what actions users can perform, and how administrative controls are enforced across your organization.

This guide explains how roles, scopes, teams, and collection ownership work together to provide secure and scalable access control.

Audience: Organization owners, superadmins, administrators, and security teams

Overview

Devici uses layered access control to balance security and flexibility:

  1. Roles — define a user’s global capabilities within the platform
  2. Scopes — define which platform objects an Admin role can access and whether access is read or write
  3. Teams — control access to collections and threat models
  4. Collection ownership — governs destructive and ownership-level actions

Scopes apply only to the Admin role and are assigned by Superadmins.
Owners and Superadmins are not scope-restricted.

User Roles

Roles define a user’s global capabilities within Devici.

Common Roles

Role Description
Owner Full control over the organization, including security, billing, and destructive actions
Superadmin Administrative control over security, users, integrations, and API tokens
Admin Manages users, teams, and collections, with scopes applied to limit access
User Builds, edits, and reviews threat models based on assigned permissions

Note
Capabilities for the Admin role are determined by scopes applied to the role.
Only Superadmins can create Admin users and assign or modify their scopes.

What Roles Control

Roles determine who is eligible to perform administrative actions.

Depending on role and applied scopes, users may be able to:

  • Configure SAML Single Sign-On (SSO)
  • Enable or manage Multi-Factor Authentication (MFA)
  • Manage users and teams
  • Configure integrations
  • Create and manage API tokens

Roles and scopes do not control access to individual threat models — that is handled through teams and collections.

Scopes

Scopes provide granular control over what the Admin role can access and manage.

Scopes allow Superadmins to limit Admin access to specific platform objects and define whether that access is read-only or read/write.

How Scopes Work

  • Scopes apply only to the Admin role
  • Scopes are created and assigned by Superadmins
  • Each scope maps to a specific platform object or administrative domain
  • Each scope supports read and write permissions
  • Access is enforced consistently across the UI and API

Admins without a required scope cannot view or modify the associated settings.

Examples of Admin Role Access with Scopes Applied

An Admin role may be configured to:

  • View users, but not create or modify them
  • Manage teams and collection access, but not security settings
  • Configure integrations, without access to SSO or API token management

This model ensures administrative access is intentional, limited, and auditable.

Creating and Managing Admins

  • Only Superadmins can create users with the Admin role
  • Admin roles must have one or more scopes applied
  • Admin roles without scopes have no administrative access

This prevents implicit privilege escalation and supports least-privilege administration.

Teams and Collection Access

Teams are used to group users and manage access to collections.

  • Teams control which collections users can access
  • Teams define permission levels within those collections
  • Permissions apply to all threat models in the collection

Using teams avoids individual user assignments and simplifies access management.

👉 See: Creating & Managing Teams

Collection Ownership

Each collection has a single Owner.

Collection ownership determines who can:

  • Delete a collection
  • Archive or restore collections
  • Transfer collection ownership

Collection ownership cannot be overridden by team permissions.

Even users with Manage permissions cannot delete a collection unless they are the collection owner.

How Roles, Scopes, Teams, and Ownership Work Together

Scenario Controlled By
Can a user configure SAML or MFA? Role (Owner / Superadmin)
Can an Admin manage users or teams? Scopes applied to the Admin role
Can a user access a collection? Team
Can a user edit threat models? Team permission level
Can a user delete a collection? Collection owner
Can an Admin access a platform object? Scope (read / write)

This separation ensures security-critical actions remain tightly controlled while enabling flexible collaboration.

Relationship to API Tokens

Scopes follow the same permission model used by API tokens to ensure consistent access control.

When an Admin role is associated with an API token:

  • The token’s permissions must not exceed the scopes applied to the Admin role
  • Tokens cannot grant broader access than the Admin already has

This prevents privilege escalation while enabling secure automation.

A common enterprise setup looks like this:

  • Owners / Superadmins
  • Platform and security administrators

  • Manage SSO, MFA, admin creation, API access, and integrations

  • Admins

  • Admin role with scopes applied to match specific responsibilities

  • Manage users, teams, collections, or integrations as assigned

  • Users

  • Engineers, architects, and security contributors
  • Build, review, and maintain threat models

This model minimizes risk while enabling broad participation.

Best Practices

  • Assign the minimum required scopes to each Admin role
  • Prefer Admin roles with scopes applied over broad Superadmin access
  • Limit Owner and Superadmin roles to a small number of trusted users
  • Use teams to manage access instead of individual permissions
  • Regularly review scopes and API token assignments

Devici’s access control model is designed to scale securely as your organization grows.