It also documents all administrator-controlled security-relevant settings, their purpose, security impact, and recommended configurations.
Last updated: 2025-12-19
Applies to: Epsilon3 customer-facing application
Audience: Customer administrators, security teams, IT administrators
This guide explains how to securely set up, configure, operate, and decommission administrative accounts in Epsilon3. It also documents all administrator-controlled security-relevant settings, their purpose, security impact, and recommended configurations.
This document is publicly accessible and does not require authentication.
1. Purpose and Scope
Epsilon3 uses role-based access control (RBAC) to ensure that administrative privileges are scoped, auditable, and aligned with least-privilege principles.
This guide covers:
Customer-facing administrative roles
How those roles are securely managed
Security-relevant settings controlled by administrators
This guide does not cover:
Epsilon3 internal or backend administrative systems
Infrastructure-level or deployment-level controls managed by Epsilon3
2. Administrative Role Model Overview
2.1 Tenant Organization Model
Customer data is broken down into following categories.
2.1.1 Organizations
An organization represents the highest organizational unit for managing all customer workspaces. Organizations do not contain much information themselves. They are mostly used for managing workspaces and reporting across them.
Settings set in the organization apply to all workspaces in the organization. Accessing organization settings requires having the Organization Admin role.
2.1.2 Workspaces
A workspace is the top-level unit for various pieces of customer data including but not limited to procedures, test plans, parts, telemetry, commanding etc. Users must be invited individually to each workspace to which they need access. Users can be given an access level that applies across the whole workspace.
2.1.3 Projects and Subprojects
Projects and subprojects are optional suborganizational units that data can be placed into. Users may be assigned a higher access level at the project level.
2.2 Roles and Responsibilities
Epsilon3 separates administrative responsibilities across organization, workspace, and project boundaries. Each administrative role has a clearly defined scope and set of allowed actions.
The highest level of operational and security authority in the application is the Workspace Admin role.
3. Administrative Role Definitions
3.1 Organization Admin
Scope: Entire organization (all workspaces)
Purpose: Organizational oversight and billing visibility
Organization Admins are intended for business and governance oversight. They have visibility into the organization as a whole but do not control operational or security configuration.
Capabilities:
View billing and subscription details
View user accounts across all workspaces
View organization-level metadata
Explicitly cannot:
Manage users access to workspaces
Assign roles
Configure security settings
Modify workflows, procedures, inventory, or skills
Change workspace or project configuration
Security impact: Low
This role provides visibility without the ability to make security-impacting changes.
3.2 Workspace Admin (Primary Administrative Role)
Scope: Single workspace
Purpose: Secure configuration and operation of Epsilon3
Workspace Admins are the primary administrative authority within Epsilon3. This role controls user access, permissions, and security-relevant configuration within a workspace.
Capabilities:
Create, update, disable, and remove users within the workspace
Assign and revoke workspace and project roles
Configure workspace settings
Manage workflows, procedures, inventory, and skills
Control access to and modification of operational data
Oversee workspace activity and usage
Security impact: High
Workspace Admins can directly affect system integrity, access control, and operational behavior.
For compliance purposes, Workspace Admin is considered the top-level administrative application account.
3.3 Project Admin
Scope: Individual project(s)
Purpose: Project-scoped administration
Project Admins have administrative privileges only within the projects to which they are assigned. This role enables delegation without granting access to broader workspace or organizational settings.
Capabilities:
Administer project-specific items such as procedures, builds, and runs
Manage project-level access where permitted
Perform admin-level actions limited to project scope
Explicitly cannot:
Modify workspace-wide settings
Access billing or organization-level data
Configure global security settings
Affect other projects or workspaces
Security impact: Medium
This role limits the blast radius of administrative actions to a single project.
4. Administrative Account Lifecycle
4.1 Admin Account Creation
Who can create Workspace Admin accounts:
Workspace Admins
Who can create Organization Admin accounts:
Organization Admins
Who can create Project Admin accounts:
Workspace Admins
Project Admins in the same project
Process:
Navigate to User Settings within the workspace
Create or invite a user
Assign Workspace Admin or Project Admin role as needed
Require the user to complete authentication setup on first login
Security guidance:
Assign admin roles only to named individuals
Avoid shared or generic admin accounts
Grant the minimum role required for job responsibilities
4.2 Authentication and MFA
Epsilon3 supports multi-factor authentication (MFA) if it is configured in conjunction with SSO through their Identity Provider.
Recommended configuration:
MFA enabled for all Workspace Admin accounts
MFA strongly recommended for Project Admin accounts
MFA recommended for Organization Admin accounts due to billing access
Security impact: Medium
Reduces risk of account compromise
Protects roles with elevated privileges
4.3 Ongoing Administration and Review
Best practices:
Review Workspace Admin assignments at least quarterly
Review Project Admin access at project milestones or completion
Remove admin privileges when no longer required
4.4 Admin Account Decommissioning
Admin accounts should be decommissioned when:
An administrator leaves the organization
Job responsibilities change
A project concludes
Access is no longer required
Decommissioning steps:
Disable or remove the user account
Reassign ownership of any owned resources if applicable
Verify no additional admin roles remain assigned
Audit history and records remain intact after deactivation.
5. Admin-Controlled Security Settings Reference
5.1 Organization Settings
Organization settings are configured by Organization Admins on the Organization Settings Screen
5.2 Organization Users
The organization users screen lists all users. It also allows organization admins the ability to control whether other users are organization admins or not.
5.3 Saml Configuration
SAML Identity provider configuration is available to organization administrators. SAML IDPs are configured organization wide. Each organization can have several Identity providers to authenticate users. Username & Password based authentication can be disabled by disabled by contacting the support team.
5.4 Team General Settings
5.5 Release Settings
Release settings control who is required to approve a new release of a procedure.
5.6 Roles Settings
Some settings affect role behavior in general.
5.7 Procedure Settings
5.8 User Settings
Workspace administrators can manage users including setting workspace access level and operator roles for each user. Users may additionally be granted higher access level and additional roles in the context of specific projects.
Workspace Access Level
Workspace access levels granted to users apply across the whole workspace. They may be granted higher access levels at the project level.
Project Level Access
Users can be granted higher level access for specific projects. For example, users could be given “None” access to the workspace, but an editor for a specific project and they would be able to manage procedures in that workspace only.
Note:
Organization Admins do not control or modify these settings.
6. Secure Operation Guidelines
Workspace Admins should:
Monitor administrative access regularly
Review changes to procedures and workflows
Ensure admin accounts remain limited to trusted users
Remove unused or unnecessary privileges promptly
7. Incident Response Considerations
If an administrative account is suspected to be compromised:
Disable the account immediately
Review relevant activity and changes
Rotate credentials as appropriate
Contact Epsilon3 Support if platform assistance is required
8. Secure Offboarding and Workspace Decommissioning
When an organization or workspace is no longer active:
Remove or disable all Workspace Admin and Project Admin accounts
Ensure no orphaned administrative access remains
Retain records as required for audit or compliance purposes
9. Alignment with FedRAMP Recommended Secure Configuration
This guide aligns with FedRAMP Recommended Secure Configuration principles by implementing:
Least privilege access
Separation of duties
Scoped administrative authority
Strong authentication for privileged users
Controlled lifecycle management of admin accounts
Additional guidance:
10. Document Stability
This Security Admin Guide is intended to remain publicly accessible at a stable URL and will be updated as Epsilon3 administrative capabilities evolve.