# Device Sessions Source: https://theodosian.com/help/command/account/device-sessions View and manage active device sessions across your web and desktop apps. The Device Sessions page shows all devices that have an active session for your account in the current tenant. You can review where your account is signed in and remotely sign out of any device you no longer recognize or need. ## Accessing Device Sessions Click **Settings** in the bottom of the sidebar navigation. In the Settings sidebar under the **Account** heading, click **Devices**. The Device Sessions page will load with a list of all your active sessions. ## Understanding Device Sessions Each device session represents an active sign-in on a specific device. Every session card displays the following information: | Field | Description | | -------------------- | -------------------------------------------------------------------------------------------------------- | | **Session type** | Either **Desktop Agent** (Theodosian Desktop App) or **Web Session** (Theodosian Command in a browser). | | **Operating system** | The OS of the device — Windows, macOS, or Linux. An OS-specific icon is displayed alongside the session. | | **Last seen** | How recently the device was active, shown as a relative time (e.g. "5 minutes ago", "2 days ago"). | | **Location** | The city and country of the device's last known location, determined by IP address. | | **Current Device** | A green label indicating the device you are currently using. | Location data is approximate and based on IP geolocation. It may not reflect the exact physical location of the device, especially when using a VPN or corporate network. ## Signing Out a Device If you see a session you do not recognize, or you want to revoke access from a device you no longer use, you can remotely sign it out. On the Device Sessions page, locate the device session you want to sign out. Click the **Sign Out** button on the right side of the device session card. A confirmation dialog will appear asking you to confirm. Click **Remove Device** to proceed. The device will be signed out immediately and removed from the list. Signing out a device terminates its session immediately. If you sign out your current device, you will be redirected to the sign-in page and will need to sign in again. ## Session Types Theodosian tracks sessions separately for each application type: | Session Type | Description | | ----------------- | --------------------------------------------------------------------------------------------- | | **Web Session** | A session created when you sign in to Theodosian Command through a web browser. | | **Desktop Agent** | A session created when you sign in to the Theodosian Desktop App on Windows, macOS, or Linux. | A single device can have both a web session and a desktop agent session if you are signed in to both applications on the same machine. ## Session Expiration Device sessions expire automatically based on the **Session Duration** configured by your tenant's administrator. The default session duration is 30 days. Once a session expires, the device is signed out automatically and will need to sign in again. For more information about session duration settings, see [Tenant Security](/help/command/tenant/tenant-security). ## Troubleshooting If you see an unfamiliar device or location, click **Sign Out** on that session immediately to revoke access. Then review your account security — consider [enabling multi-factor authentication](/help/command/account/multi-factor-authentication) if you have not already, and contact your tenant administrator if you suspect unauthorized access. Device locations are determined by IP-based geolocation, which can be inaccurate. If you are using a VPN, proxy, or corporate network, the reported location may reflect the network exit point rather than your physical location. This is expected behavior and does not indicate a security issue. The device list refreshes after a sign-out action. If the device still appears, try refreshing the page. If the issue persists, the sign-out may not have completed — try again or contact [support](https://theodosian.com/support). You will be redirected to the sign-in page. Simply sign in again with your email address, verify via the magic link, and complete MFA verification if required. Your data and settings are not affected. If the device list shows "No devices found", it means there are no active sessions registered for your account in the current tenant. This can happen if sessions have expired or were recently cleared. You should still have an active session on your current device — try refreshing the page. # Multi-Factor Authentication Source: https://theodosian.com/help/command/account/multi-factor-authentication Set up and manage TOTP-based multi-factor authentication for your account. Multi-factor authentication (MFA) adds an extra layer of security to your Theodosian account by requiring a time-based verification code in addition to your email verification when signing in. Theodosian uses TOTP (Time-based One-Time Password) codes generated by an authenticator app on your phone or device. MFA can be made mandatory for all users in a tenant by a Global Administrator. See [Tenant Security](/help/command/tenant/tenant-security) for details on enforcing MFA across your organization. ## How MFA Works in Theodosian When MFA is enabled on your account, the sign-in process includes an additional verification step: 1. You sign in with your email and verify via the magic link as usual. 2. After email verification and tenant selection, you are presented with an MFA verification screen. 3. You enter the 6-digit code from your authenticator app. 4. Once verified, you are signed in to the dashboard. If your tenant has MFA enforcement enabled but you have not yet set up MFA, you will be guided through the setup process before you can access the dashboard. ## Setting Up MFA You can enable MFA from the Account Security settings page. Click **Settings** at the bottom of the sidebar, then select **Security** under the **Account** heading. In the **Multi-Factor Authentication** row, click the **Enable** button. A multi-step setup modal will open with a sidebar showing the two setup steps: **Scan QR Code** and **Verify Code**. The sidebar highlights **Scan QR Code** as the current step. Open your authenticator app (such as Google Authenticator, Microsoft Authenticator, Authy, or 1Password) and scan the QR code displayed in the modal. If you cannot scan the QR code, click **Show manual entry code** to reveal the secret key. You can copy this key and manually add it to your authenticator app. Click **Next** once you have added the account to your authenticator app. The sidebar will advance to **Verify Code**. Your authenticator app will now display a 6-digit code that refreshes every 30 seconds. Enter the current code into the **Verification Code** field and click **Verify & Enable**. Click **Back** to return to the QR code step if needed. If the code is valid, MFA will be enabled on your account immediately. A success message will confirm the setup, and a status badge will appear next to the Multi-Factor Authentication setting indicating that MFA is active. Make sure to save the secret key or keep your authenticator app backed up. If you lose access to your authenticator app, you will need to contact your tenant administrator to reset your MFA. ## Verifying MFA During Sign-In After MFA is enabled, each time you sign in to Theodosian Command you will see a dedicated MFA verification screen after completing email verification and tenant selection. After selecting your tenant, you will be presented with the **Multi-Factor Authentication** verification screen. It displays the tenant you are signing in to. Type the current 6-digit code from your authenticator app into the **Verification Code** field. Click **Verify & Continue** to complete the sign-in. If the code is valid, you will be redirected to the dashboard with a welcome message. MFA verification is per-session. Once you have verified, you will not be prompted again until your session expires or you sign out and sign back in. ## MFA Setup Required by Your Organization If your tenant administrator has [enforced MFA](/help/command/tenant/tenant-security) and you have not yet set it up, you will be automatically guided through the setup process when you sign in. This works the same way as the manual setup described above — scan the QR code, enter the verification code, and you will be signed in once verification succeeds. You will not be able to access the dashboard or any other part of Theodosian Command until MFA is configured. ## Disabling MFA If MFA is not enforced by your tenant, you can disable it from the Security settings page. Click **Settings** at the bottom of the sidebar, then select **Security** under the **Account** heading. In the **Multi-Factor Authentication** row, click the **Disable** button. A confirmation dialog will appear with a warning that disabling MFA will make your account less secure. To confirm the action, enter the current 6-digit code from your authenticator app and click **Disable MFA**. MFA will be disabled on your account. The status badge will be removed from the Security settings page. Disabling MFA removes an important layer of protection from your account. We recommend keeping MFA enabled at all times. If your tenant administrator has enforced MFA, the **Disable** button will be greyed out and you will not be able to turn off MFA. A tooltip will indicate that you should contact your administrator. The administrator can reset your MFA from the user management panel if needed. ## Supported Authenticator Apps Theodosian MFA works with any authenticator app that supports the TOTP standard (RFC 6238). Popular options include: | App | Platforms | | --------------------------- | -------------------------------------------- | | **Google Authenticator** | iOS, Android | | **Microsoft Authenticator** | iOS, Android | | **Authy** | iOS, Android, Desktop | | **1Password** | iOS, Android, macOS, Windows, Linux, Browser | | **Bitwarden** | iOS, Android, macOS, Windows, Linux, Browser | ## Troubleshooting TOTP codes are time-sensitive and refresh every 30 seconds. Make sure the clock on your device is accurate — even a small time drift can cause codes to be rejected. Check your device's date and time settings and enable automatic time synchronization if available. If you can no longer access your authenticator app, contact your tenant administrator. An administrator with User Management permissions can reset your MFA from the user management panel, allowing you to set it up again on your next sign-in. During MFA setup, click **Show manual entry code** below the QR code to reveal your secret key. Copy the secret key and manually add it to your authenticator app using the app's manual entry option. Your tenant administrator has enforced MFA for all users. When MFA enforcement is active, individual users cannot disable MFA on their own accounts. Contact your administrator if you need assistance. Your tenant administrator has enabled MFA enforcement, which requires all users to configure MFA. You must complete the setup to continue using Theodosian Command. This is a one-time process — once set up, you will only need to enter your verification code when signing in. # Passkeys Source: https://theodosian.com/help/command/account/passkeys Register and manage WebAuthn passkeys for secure, phishing-resistant authentication. Passkeys provide a modern, phishing-resistant way to authenticate with Theodosian. Built on the WebAuthn standard, passkeys use cryptographic key pairs stored on your device or hardware security key — meaning there is no shared secret that can be intercepted or phished. You can register multiple passkeys on your account and remove them at any time from the Security settings page. Passkeys are an additional security layer on your account. They work alongside [multi-factor authentication](/help/command/account/multi-factor-authentication) and the magic link sign-in flow — they do not replace them. ## Supported Authenticators Theodosian supports any FIDO2/WebAuthn-compatible authenticator, including: | Authenticator Type | Examples | | --------------------------- | ------------------------------------------------------------ | | **Platform authenticators** | Windows Hello, macOS Touch ID / Face ID, Android biometrics | | **Hardware security keys** | YubiKey 5 series, Google Titan, Feitian, SoloKeys | | **Password managers** | 1Password, Bitwarden, Dashlane, Proton Pass, iCloud Keychain | | **Browser-based** | Chrome, Edge, Safari, and Firefox built-in passkey support | Theodosian automatically identifies your authenticator type and displays the appropriate name and icon in your passkey list. ## Registering a Passkey Navigate to **Settings** → **Security** under the **Account** heading in the sidebar. In the **Passkeys** section, click the **Setup a new Passkey** button. Your browser will display a native passkey registration prompt. Depending on your device and browser, you may be asked to: * **Use a platform authenticator** — Verify with Touch ID, Face ID, Windows Hello, or a device PIN. * **Use a hardware security key** — Insert and tap your security key. * **Use a password manager** — Select a passkey provider from your browser's list. Follow the on-screen instructions to complete registration. Once registration is verified, a success message will appear confirming that your passkey has been set up. The new passkey will immediately appear in your passkey list. You can register multiple passkeys on your account — for example, one for your laptop's biometric sensor and another on a hardware security key as a backup. ## Viewing Your Passkeys All registered passkeys are listed in the **Passkeys** section on the Security settings page. Each passkey displays: | Field | Description | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Authenticator name** | The type of authenticator used (e.g. "iCloud Keychain", "YubiKey 5 Series", "1Password"). If the authenticator is not recognized, it will display as "Unknown Authenticator". | | **Created** | How long ago the passkey was registered (e.g. "2 days ago"). | ## Removing a Passkey If you no longer use a particular authenticator or want to clean up your passkey list, you can remove individual passkeys. On the Security settings page, scroll to the **Passkeys** section and locate the passkey you want to remove. Click the **Remove** button on the right side of the passkey card. The passkey will be removed immediately and a success message will confirm the deletion. The authenticator can no longer be used to authenticate with your account. Removing a passkey is permanent. If you remove a passkey by mistake, you will need to register it again by going through the setup process. ## Troubleshooting Make sure you are using a browser that supports WebAuthn passkeys. All major modern browsers (Chrome, Edge, Safari, Firefox) support passkeys. If you are using an older browser version, try updating it. Also ensure that your device has a compatible authenticator available (e.g. biometric sensor, hardware key, or password manager with passkey support). This can happen if: * **You cancelled the browser prompt** — The registration is aborted if you dismiss the browser's passkey dialog. Try again and complete the prompt. * **The authenticator is already registered** — If you have already registered a passkey with the same authenticator, the browser may reject a duplicate. Check your passkey list to see if it is already there. * **Your security key is not recognized** — Make sure your hardware security key is properly inserted and supports FIDO2/WebAuthn. Theodosian identifies authenticators using a database of known device identifiers (AAGUIDs). If your authenticator is new or uncommon, it may not be in the database yet. The passkey will still work normally — only the display name is affected. Yes. Passkeys are an additional authentication method. You can always sign in using the standard magic link email flow. Removing all passkeys does not lock you out of your account. # Profile Management Source: https://theodosian.com/help/command/account/profile-management Update your name, email address, nationality, and profile picture. The Profile page lets you manage your personal account details within Theodosian Command. You can update your display name, email address, nationality, and profile picture from the Account Settings page. Updating your name, email, and nationality requires **User Management** permission. If you do not have this permission, the update buttons will be disabled. Contact your tenant administrator to request access. ## Accessing Your Profile Click **Settings** at the bottom of the sidebar navigation. The sidebar will switch to the settings panel. Under the **Account** heading in the settings sidebar, click **Profile**. The Account Settings page will load with your current details. ## Updating Your Name Your display name is shown throughout Theodosian Command — in the sidebar, user lists, audit logs, and anywhere your identity is referenced. On the Account Settings page, find the **Name** row displaying your current name. Click the **Update Name** button on the right. A dialog will appear with your current name pre-filled. Edit the **Name** field to your desired display name. Click **Save Changes** to apply the update. A confirmation message will appear once the name has been updated successfully. The change is reflected across the platform immediately. ## Updating Your Email Address Your email address is used for signing in to Theodosian Command and receiving notifications, including magic link sign-in emails. On the Account Settings page, find the **Email Address** row displaying your current email. Click the **Update Email** button on the right. A dialog will appear with your current email address pre-filled. Update the **Email Address** field to your new email. Click **Save Changes** to apply the update. A confirmation message will appear once the email has been updated successfully. After changing your email address, you will need to use the new email to sign in. Make sure you have access to the new email inbox before making this change, as future magic link sign-in emails will be sent to the updated address. ## Updating Your Nationality Your nationality is used by [access control workflows](/help/command/protection-policies/access-controls) that include a User Nationality condition block. If your organization uses nationality-based access controls, keeping this value up to date ensures you can access the files you need. On the Account Settings page, find the **Nationality** row displaying your current nationality (or "Not specified"). Click the **Update Nationality** button on the right. A dialog will appear with a searchable dropdown. Search for and select your nationality from the list. To clear your nationality, remove the current selection. Click **Save Changes** to apply the update. A confirmation message will appear once the nationality has been updated successfully. It is your organization's responsibility to validate user nationality. Theodosian does not independently verify this value. ## Profile Picture Your profile picture appears in the sidebar, user lists, and other areas where your account is displayed. It helps team members identify you visually, especially in tenants with many users. ### Uploading a Profile Picture On the Account Settings page, find the **Profile Picture** row. Hover over the avatar on the right — a cloud upload icon will appear. Click on it to open the file picker. Choose an image file from your computer. The image must meet the following requirements: | Requirement | Details | | ---------------- | --------------------------------------------- | | **File type** | Any image format (PNG, JPEG, WebP, GIF, etc.) | | **Maximum size** | 1 MB | The profile picture uploads automatically after you select a file. A confirmation message will appear once the upload is complete. Your new avatar will be visible across Theodosian Command immediately. ### Removing a Profile Picture If you already have a profile picture, a **Clear Avatar** link will appear below the image. Click it to remove the profile picture and revert to the default avatar (which displays your initials). The removal is applied automatically. ## Settings Summary | Setting | Description | Permission Required | | ------------------- | ------------------------------------------------------------- | ------------------- | | **Name** | Your display name shown across the platform. | User Management | | **Email Address** | The email used for signing in and receiving notifications. | User Management | | **Nationality** | Your nationality, used for nationality-based access controls. | User Management | | **Profile Picture** | A personal avatar displayed alongside your account. | User Management | ## Troubleshooting You need **User Management** permission to update your profile details (name, email, and nationality). This permission is granted through [Security Groups](/help/command/users/security-groups). Contact your tenant administrator to be added to a security group that includes this permission. Ensure your image file is under 1 MB and is a valid image format. If the file is too large, resize or compress it before uploading. If the issue persists, try a different image file or a different browser, or contact [support](https://theodosian.com/support). After updating your email, all future sign-in magic links will be sent to the new address. Make sure you are entering the updated email on the sign-in page. If you no longer have access to the new email, contact your tenant administrator — they can update your email from the [User Management](/help/command/users/manage-users) page. Profile changes take effect immediately. If you still see outdated information, try refreshing the page. In some cases, cached data may take a moment to update across all areas of the platform. # Signing In Source: https://theodosian.com/help/command/account/signing-in Sign in to Theodosian Command using passwordless magic link authentication. Theodosian Command uses **passwordless authentication** — there are no passwords to create or remember. Instead, you sign in by verifying your identity through a magic link sent to your email address. ## Sign In Steps Open [Theodosian Command](https://dash.theodosian.com/signin) in your browser. If you already have an active session, you will be redirected to your dashboard automatically. Type the email address associated with your Theodosian account into the email field and click **Sign In**. A bot verification check will appear before your request is submitted. This is a one-time security step to confirm you are not automated traffic. A confirmation screen will appear with the message **Check your email**. Open your email inbox and look for a sign-in message from Theodosian containing a magic link. Click the magic link in the email to verify your identity. The link will open Theodosian Command in your browser and begin the verification process. If you don't receive the email, click the **Didn't receive the email? Try again.** link on the confirmation screen to return to the sign-in page and request a new magic link. After your identity is verified, what happens next depends on how many tenants are associated with your email: * **Single tenant** — You are signed in automatically and redirected to the dashboard. * **Multiple tenants** — A tenant selection screen appears, displaying all tenants linked to your email. Click the tenant you want to sign in to. Depending on the tenant and your account status, Theodosian may show one or more legal acceptance screens before you reach the dashboard. Global Administrators may first need to accept updated [Terms of Service](/help/command/legal/terms-of-service) for the tenant. Users may then be asked to accept the [End User License Agreement and Services Privacy Policy](/help/command/legal/user-agreements) if required. If multi-factor authentication is enabled on your account or enforced by your tenant, you will be prompted to enter a 6-digit verification code from your authenticator app. * **MFA already configured** — Enter the code from your authenticator app and click **Verify & Continue**. * **MFA enforced but not yet configured** — You will be guided through the MFA setup process. Scan the QR code with your authenticator app, then enter the generated code to complete setup. See [Multi-Factor Authentication](/help/command/account/multi-factor-authentication) for details. Once verified, you will be redirected to the tenant dashboard. ## Creating a New Account If you don't have a Theodosian account yet, you can sign up by navigating to the [sign-up page](https://dash.theodosian.com/signup). On the sign-up page, enter the email address you want to use for your account and click **Sign Up**. Check your inbox for a magic link from Theodosian. Click the link to verify your email address. After verification, you will be guided through the [tenant creation process](/help/command/tenant/creating-a-tenant) to set up your organization. Already have an account? Click the **Already have an account? Sign in instead!** link on the sign-up page to return to the sign-in flow. ## Accepting an Invitation If you have been invited to join an existing tenant by an administrator, you will receive an invitation email. Click the link in the invitation to sign in and join the tenant. You do not need to create a new account or tenant — the invitation will associate your email with the existing tenant automatically. ## Staying Signed In Theodosian Command remembers your session in your browser. You do not need to sign in again each time you visit, unless: * Your session has expired. Session duration is configured by your tenant administrator — see [Tenant Security](/help/command/tenant/tenant-security) for details. * You have explicitly signed out. * Your browser data has been cleared. If you are a member of multiple tenants, your sessions are managed independently. Signing out of one tenant does not affect your sessions in other tenants. See [Switching Tenants](/help/command/tenant/switching-tenants) for more information. ## Troubleshooting Check your spam or junk folder. If the email still hasn't arrived after a minute, return to the sign-in page and try again. Make sure you are entering the correct email address associated with your Theodosian account. Magic links are valid for a limited time. If your link has expired, go back to the sign-in page and request a new one by entering your email address again. If your email address is not associated with any tenant, you will be shown a tenant not found screen after clicking the magic link. This means you have not been invited to any tenant yet. Ask your organization's administrator to invite you, or [create a new tenant](/help/command/tenant/creating-a-tenant) by signing up instead. Make sure you are entering the correct 6-digit code from your authenticator app. Codes refresh every 30 seconds, so ensure you are using the most recent one. If you have lost access to your authenticator app, contact your tenant administrator to reset your MFA. Your session may have expired. Session duration is set by your tenant administrator and can range from 1 day to several weeks. Sign in again with your email to start a new session. # Anomalous Activity Detection Source: https://theodosian.com/help/command/anomalous-activity/anomalous-activity-detection Understand how Theodosian continuously scores user risk and which behavioral signals drive those scores. Theodosian's Anomalous Activity Detection module continuously monitors user behavior across your tenant and computes a real-time risk score for each user. Scores are recalculated automatically every time a new compliance event is ingested, and decay over time in the absence of new activity. When a user's score rises, it is an early indicator that their account may be compromised or that they are exhibiting behavior outside their normal baseline. You must have the **Anomalous Activity Detection View** permission to query risk scores and detector data via the API. The **Anomalous Activity Detection Manage** permission is required to modify detector sensitivity. ## How Scoring Works Each user has a single risk score between **0** and **100**. The score is derived from a set of independent behavioral detectors, each of which emits a **confidence** value (0–1) when it observes a relevant event. All of the detectors **confidence** values are added, according to the sensitivy configuration into a final score. There is also a decay mechanism that makes sure older signals are treated as less significants and that triggers a decay in score naturaly if user start behaving according to expected parameters. ## Detectors The module includes nine independent detectors. Each detector monitors a specific type of event and computes a confidence value when it fires. | Detector | What It Watches | Default Sensitivity | Scope | | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | :-----------------: | -------------- | | **Impossible Travel** | Authentication events from geographically implausible locations (speed >900 km/h between successive login locations) | High | User | | **MFA Activity** | Detects MFA related activities within a short window. | Moderate | User | | **File Access Spike** | Identifies users whose file session usage rate significantly exceeds the tenant-wide baseline. | Low | User + Company | | **Bulk Removal** | Detects mass deletion of policies, encryption from files, or security groups attributed to a user within a short period window. | Moderate | User | | **Unauthorized File Access** | Counts repeated file decryption failures for a user within a short window, indicating attempts to access files without proper authorization. | Moderate | User | | **Failed Authentication** | racks authentication failures attributed to a user and tenant anonymous token-guessing attempts from the same period. | Moderate | User + Company | | **Login Activity** | Flags users with an unusually high number of successful logins within a short period. | Minimal | User | | **Network Connection** | Assigns risk based on network anonymization signals detected on each event | Low | User | | **Off-Hours Activity** | Detects activity outside the tenant's established usage hours both on weekdays and weekends. | Minimal | User + Company | ### Baseline Readiness Some detectors may require historical data before they become active. Until a detector's baseline requirement is met, it is displayed as **Calibrating** and does not emit signals. You can check the readiness status of all detectors via the [Get Detector Stats](/help/api/anomalous-activity/get-detectors-stats) API endpoint. ## Data Retention Risk scores and detector confidence records are retained for **90 days**. ## Customizing Detector Sensitivity Each detector has a default weight that represents its relative contribution to the final risk score. Weights can be adjusted **per tenant** to reflect your organization's threat model — for example, you might increase the sensitivity of Impossible Travel if your users are geographically concentrated, or reduce the sensitivity of Network Connection if VPN use is common in your environment. Detectors ship with one of four default sensitivity levels: | Sensitivity | Description | | ------------ | --------------------------------------------------------------------------------------------------------------------------------------- | | **Maximum** | Highest possible contribution to the risk score. Signals from this detector dominate the final score. | | **High** | Strong contribution to the risk score. Signals from this detector have a large impact on the final score. | | **Moderate** | Meaningful contribution. These detectors are reliable signals of suspicious activity but are weighted below high-sensitivity detectors. | | **Low** | Supplementary signal. These detectors add context to the risk score but have a smaller individual impact. | | **Minimal** | Weak contribution. These detectors provide background context and are unlikely to drive a high score on their own. | | **Off** | The detector is disabled and does not contribute to the risk score. | Weights are managed via the [Update Detector Sensitivity](/help/api/anomalous-activity/update-detector-weight) API endpoint. You can reset any detector back to its default weight at any time. # Drop the Gate on Protection Policies Source: https://theodosian.com/help/command/anomalous-activity/drop-the-gate-on-protection-policies Instantly revoke access to all files under a protection policy by dropping the gate. Drop the Gate on a protection policy is an emergency security action that immediately blocks all access to files encrypted under a specific protection policy. When you drop the gate on a policy, no user — regardless of their role or membership — can access or modify files governed by that policy. New data can still be added to the protection policy, but existing encrypted files become inaccessible until the gate is removed. This is designed for situations where you suspect a data breach affecting files under a specific policy, need to immediately lock down a category of sensitive data, or want to halt access to a specific set of protected files while you investigate a security concern. You must have the **Protection Policies** permission to drop the gate on a protection policy. By default, users in the **Global Administrator** security group have this permission. ## What Happens When You Drop the Gate on a Protection Policy When the gate is dropped on a protection policy, the following occurs immediately: 1. **All file access is blocked** — No user can decrypt, open, or modify files that are encrypted under this protection policy. This applies to all members of the policy, including administrators. 2. **New data can still be added** — Files can still be encrypted and added to the protection policy, but they will be inaccessible until the gate is removed. 3. **Email notification is sent** — Users with Policy Management permissions are notified via email that the gate has been dropped on the policy. 4. **Compliance event is logged** — A compliance audit event is recorded for tracking and accountability purposes. 5. **Visual indicators are updated** — A red **Gate Dropped** badge appears next to the policy name across Theodosian Command, and an informational banner is displayed on the policy's details page. Dropping the gate on a protection policy immediately blocks file access for **all users** governed by that policy — including policy administrators. Any user who is in the middle of working with a file under this policy will lose access immediately. Ensure this is the intended action before proceeding. ## Dropping the Gate on a Protection Policy In the sidebar, click **Protection Policies** to open the Protection Policies list page. Find the protection policy you want to lock down and click on its row to open the policy details page. On the policy details page, click the **Drop the Gate** tab. This is the fourth tab, after Security Groups, Users, and Access Controls. Toggle the **Drop the Gate** switch to the on position. A confirmation dialog will appear. Review the confirmation message carefully: > *"Please confirm you want to drop the gate on this protection policy. This will prevent all data in this protection policy from being accessed or changed. New data can still be added to the protection policy."* Click **Proceed** to confirm. The gate will be dropped immediately. You will see a success notification confirming that Drop the Gate has been enabled for the protection policy. ## Removing the Gate from a Protection Policy When the security concern has been resolved and you are ready to restore access to the policy's files, you can remove the gate. Removing the gate does not require a confirmation dialog. In the sidebar, click **Protection Policies**, then click on the policy whose gate you want to remove. Click the **Drop the Gate** tab on the policy details page. Toggle the **Drop the Gate** switch to the off position. The gate will be removed immediately, and access to the policy's files will be restored. You will see a success notification confirming that Drop the Gate has been disabled for the protection policy. When you remove the gate, access is restored immediately. Users who are members of the policy can resume accessing files as normal, subject to any [access controls](/help/command/protection-policies/access-controls) configured on the policy. ## Identifying Policies with a Dropped Gate When the gate has been dropped on a protection policy, visual indicators appear across Theodosian Command to make the status immediately clear: ### Gate Dropped Badge A red **Gate Dropped** badge appears next to the policy name in the **Protection Policies list page**. This badge is visible to all users who have access to the Protection Policies page, making it easy to identify locked-down policies at a glance. ### Info Bar on Policy Details When you open the details page of a policy that has its gate dropped, an informational banner is displayed at the top of the page: > *"Drop the Gate has been enabled for this protection policy. No data is able to be accessed."* This banner appears on every tab of the policy details page (Security Groups, Users, Access Controls, and Drop the Gate) so that administrators are always aware of the policy's locked state. ### Tenant-Level Gate Override If the gate has been dropped at the **tenant level** (rather than the policy level), the policy details page shows a different info bar: > *"Drop the Gate has been enabled at tenant level. No data is able to be accessed."* This indicates that the access block is coming from the tenant-level gate, not the individual policy gate. In this case, removing the policy-level gate will not restore access — the tenant-level gate must be removed as well. ## Relationship to Other Gate Levels Drop the Gate operates at three levels in Theodosian — users, protection policies, and the entire tenant. Understanding how these levels interact is important for managing access during a security event: | Level | Scope | Effect on this policy's files | | ---------------------------------------------------------------------- | --------------------------- | -------------------------------------------------------------------------------------------------------------- | | **[User](/help/command/anomalous-activity/drop-the-gate-on-users)** | Individual user | Only the specific user is blocked. Other members of the policy can still access files. | | **Protection Policy** | All files under this policy | All users are blocked from accessing files under this specific policy, regardless of their membership or role. | | **[Tenant](/help/command/anomalous-activity/drop-the-gate-on-tenant)** | Entire tenant | All users in the tenant are blocked from accessing any encrypted data, including files under this policy. | ### How the Levels Interact * **Policy gate + User gate** — If the gate is dropped on both a policy and a specific user, removing the policy gate will not restore access for that user. The user-level gate must also be removed. * **Policy gate + Tenant gate** — If the gate is dropped on both a policy and the entire tenant, the tenant gate takes precedence. Removing the policy gate alone will not restore access — the tenant gate must also be removed. * **Multiple policies** — Each protection policy has its own independent gate. Dropping the gate on one policy does not affect other policies. You can drop the gate on multiple policies simultaneously if needed. ## What Is and Isn't Affected | Action | Affected? | Details | | ---------------------------------------------------------------------------------------------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Opening/decrypting existing files | ✅ Blocked | No user can open or decrypt files encrypted under this policy. | | Modifying existing files | ✅ Blocked | No user can make changes to files encrypted under this policy. | | Encrypting new files under this policy | ❌ Not blocked | New files can still be encrypted and added to the policy. They will be inaccessible until the gate is removed. | | Viewing the policy's settings | ❌ Not blocked | Administrators can still view and manage the policy's membership, access controls, and settings. | | Adding or removing policy members | ❌ Not blocked | Membership changes can still be made while the gate is dropped. | | [Encryption automations](/help/command/data-connectors/encryption-automations) targeting this policy | ❌ Not blocked | Automation rules that assign this policy to newly encrypted files will continue to run. The files will be encrypted but inaccessible until the gate is removed. | ## Use Cases If you have reason to believe that files under a specific protection policy have been compromised or are being accessed inappropriately, drop the gate on that policy to immediately halt all access. This allows you to contain the incident to a specific set of files without disrupting access to other data in the tenant. If a regulatory event requires you to immediately restrict access to a specific category of data — such as ITAR-controlled files, financial records, or personal data — drop the gate on the relevant protection policy. This provides an auditable, instant lockdown that can be demonstrated to regulators. If you are investigating a security incident and want to proactively lock down certain sensitive data while you assess the scope of the issue, dropping the gate on the relevant policies provides an immediate, reversible lockdown without affecting the rest of the tenant. When a security concern is limited to files under a specific policy, dropping the gate at the policy level is less disruptive than [dropping the gate on the entire tenant](/help/command/anomalous-activity/drop-the-gate-on-tenant). Only users who need access to that specific policy's files are affected, while the rest of the organization continues working normally. ## Troubleshooting The **Drop the Gate** tab is visible on every protection policy's details page, but you must have the **Protection Policies** permission to access the policy details page in the first place. If you cannot see the Protection Policies page at all, check your security group membership to confirm you have the required permission. Check whether the gate has also been dropped at a higher level: * **Tenant level** — If the gate is dropped on the entire tenant, no one can access any encrypted data until the tenant gate is removed. Check the [Tenant Security](/help/command/tenant/tenant-security) page. * **User level** — If the gate is dropped on a specific user, that user cannot access any files until their individual gate is removed, even if the policy gate has been lifted. Check the user's profile under the [Drop the Gate tab](/help/command/anomalous-activity/drop-the-gate-on-users). If the info bar reads *"Drop the Gate has been enabled at tenant level"*, this means a Global Administrator has dropped the gate on the entire tenant — not just this policy. The tenant-level gate overrides all policy-level gates. Contact your Global Administrator to determine whether the tenant-level gate should be removed. You can immediately remove the gate by toggling the switch back to the off position on the policy's **Drop the Gate** tab. Access to the policy's files will be restored right away. A compliance audit event will be logged for both the drop and the removal, providing a full record of what occurred. This is expected behavior. Dropping the gate blocks access to files, but does not prevent new files from being encrypted and assigned to the policy. This includes files encrypted by [encryption automation rules](/help/command/data-connectors/encryption-automations) that target this policy. The newly encrypted files will become accessible once the gate is removed. Currently, Drop the Gate is applied to protection policies one at a time through each policy's details page. To lock down multiple policies, repeat the process for each one. If you need to block access to all encrypted data across the tenant, consider [dropping the gate on the entire tenant](/help/command/anomalous-activity/drop-the-gate-on-tenant) instead. # Drop the Gate on Tenant Source: https://theodosian.com/help/command/anomalous-activity/drop-the-gate-on-tenant Immediately revoke all access to encrypted data across your entire tenant in response to a critical security event. Drop the Gate on a tenant is the most powerful emergency security action in Theodosian. When activated, it immediately blocks all access to every piece of encrypted data across the entire tenant. No user — regardless of their role, security group membership, or protection policy membership — can decrypt, open, or modify any encrypted file until the gate is removed. This is the ultimate kill switch, designed for critical security scenarios such as a suspected organization-wide breach, a compliance-mandated lockdown, or any situation where you need to immediately and completely halt all access to encrypted data while you assess the situation. Dropping the gate on a tenant affects **every user** in your organization. No encrypted data can be accessed by anyone until a Global Administrator explicitly removes the gate. This action should only be used in genuine emergency situations. For more targeted responses, consider [dropping the gate on individual users](/help/command/anomalous-activity/drop-the-gate-on-users) or [specific protection policies](/help/command/anomalous-activity/drop-the-gate-on-protection-policies) instead. You must be a member of the **Global Administrator** security group to drop the gate on a tenant. This action is not available to users with any other permission level. ## What Happens When You Drop the Gate on a Tenant When the gate is dropped on the entire tenant, the following occurs immediately: 1. **All encrypted data access is blocked** — No user in the tenant can decrypt, open, or modify any encrypted file. This applies across all protection policies, all security groups, and all users — including Global Administrators. 2. **New data can still be encrypted** — Files can still be encrypted and added to protection policies, but they will be inaccessible until the gate is removed. 3. **Email notification is sent** — All tenant administrators are notified via email that the gate has been dropped on the tenant. 4. **Compliance event is logged** — A compliance audit event is recorded for tracking and accountability purposes. 5. **Visual indicators are updated** — An informational banner is displayed on every protection policy's details page, alerting administrators that the tenant-level gate is active. Dropping the gate on the tenant does **not** sign users out of Theodosian Command or prevent them from signing in. Users can still access the web panel and manage settings — they simply cannot access any encrypted file content. This is different from [dropping the gate on a user](/help/command/anomalous-activity/drop-the-gate-on-users), which locks the user out of Theodosian entirely. ## Dropping the Gate on the Tenant In the sidebar, click **Settings** at the bottom of the navigation. Under the **Tenant** heading, click **Security** to open the Tenant Security page. Scroll down to the **Drop the Gate on Tenant** setting. The description reads: *"This will Drop the Gate on the entire tenant. No data encrypted with this tenant will be able to be accessed."* Toggle the **Drop the Gate on Tenant** switch to the on position. A confirmation dialog will appear. Review the confirmation message carefully: > *"Please confirm you want to drop the gate on this entire tenant. This will prevent all data encrypted in this tenant from being able to be accessed or changed. New data can still be encrypted and added to protection policies."* Click **Proceed** to confirm. The gate will be dropped immediately. You will see a success notification confirming: *"Drop the Gate has been enabled. No data encrypted with this tenant can be accessed."* ## Removing the Gate from the Tenant When the emergency has been resolved and you are ready to restore access to all encrypted data, you can remove the gate. Removing the gate does not require a confirmation dialog. In the sidebar, click **Settings**, then under the **Tenant** heading, click **Security** to open the Tenant Security page. Find the **Drop the Gate on Tenant** setting and toggle the switch to the off position. The gate will be removed immediately. You will see a success notification confirming: *"Drop the Gate has been removed. All data encrypted with this tenant can now be accessed."* When you remove the tenant gate, access is restored immediately across the entire tenant. All users who are members of their respective protection policies can resume accessing encrypted files, subject to any [access controls](/help/command/protection-policies/access-controls) and any user-level or policy-level gates that may still be active. ## Visual Indicators When the tenant gate is active, the following visual indicators help administrators understand the current state: ### Tenant Security Page The **Drop the Gate on Tenant** toggle switch on the [Tenant Security](/help/command/tenant/tenant-security) page shows the current gate status. When the gate is active, the toggle is in the on position. ### Protection Policy Details Pages When the tenant gate is active, every protection policy's details page displays an informational banner at the top: > *"Drop the Gate has been enabled at tenant level. No data is able to be accessed."* This banner appears regardless of whether the individual policy also has its own gate dropped. It ensures that any administrator viewing a policy understands that the access block is coming from the tenant level, not the policy level. ### Distinguishing Tenant-Level from Policy-Level Gates If a protection policy has its own gate dropped **and** the tenant gate is also active, the tenant-level banner takes priority. The policy details page will show the tenant-level message rather than the policy-level message. This is because the tenant gate is the broader, overriding control — even if you remove the policy-level gate, access will remain blocked until the tenant gate is also removed. ## Relationship to Other Gate Levels Drop the Gate operates at three levels in Theodosian. The tenant level is the broadest and overrides all other levels: | Level | Scope | Relationship to tenant gate | | ---------------------------------------------------------------------------------------------- | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **[User](/help/command/anomalous-activity/drop-the-gate-on-users)** | Individual user | User-level gates are independent. A user with their gate dropped will remain locked out even after the tenant gate is removed, until their individual gate is also removed. | | **[Protection Policy](/help/command/anomalous-activity/drop-the-gate-on-protection-policies)** | All files under a policy | Policy-level gates are independent. A policy with its gate dropped will remain locked down even after the tenant gate is removed, until the policy gate is also removed. | | **Tenant** | Entire tenant | Overrides all other levels. When the tenant gate is active, no encrypted data can be accessed regardless of user or policy gate status. | ### How the Levels Interact * **Tenant gate active** — All access is blocked. Removing a user-level or policy-level gate will have no visible effect while the tenant gate remains active. * **Tenant gate removed** — Access is restored for all users and policies, **except** those that have their own individual gates still active. Any user-level or policy-level gates that were independently dropped remain in effect. * **Independent operation** — Dropping the tenant gate does not automatically drop gates on individual users or policies. Conversely, removing the tenant gate does not automatically remove any existing user-level or policy-level gates. After removing the tenant gate, review any user-level and policy-level gates that may still be active. Navigate to the [User Management](/help/command/users/manage-users) page to check for users with the **Gate Dropped** badge, and the [Protection Policies](/help/command/protection-policies/overview) page to check for policies with the **Gate Dropped** badge. ## What Is and Isn't Affected | Action | Affected? | Details | | ------------------------------------------------------------------------------ | ------------- | ----------------------------------------------------------------------------------------------------------------------- | | Opening/decrypting any encrypted file | ✅ Blocked | No user can open or decrypt any file encrypted under this tenant. | | Modifying any encrypted file | ✅ Blocked | No user can make changes to any encrypted file. | | Signing in to Theodosian Command | ❌ Not blocked | Users can still sign in and access the web panel. | | Managing users, groups, and policies | ❌ Not blocked | Administrators can still manage tenant settings, users, security groups, and protection policies. | | Encrypting new files | ❌ Not blocked | New files can still be encrypted and added to protection policies. They will be inaccessible until the gate is removed. | | [Encryption automations](/help/command/data-connectors/encryption-automations) | ❌ Not blocked | Automation rules continue to run and encrypt new files. Encrypted files will be inaccessible until the gate is removed. | | Desktop app file access | ✅ Blocked | The desktop app cannot decrypt or open any encrypted files while the tenant gate is active. | ## When to Use Tenant-Level Drop the Gate Dropping the gate at the tenant level is the most disruptive emergency action available in Theodosian. It should be reserved for situations where the scope of the security concern justifies blocking all access across the organization: If you suspect that the entire tenant has been compromised — for example, if encryption keys may have been exposed, or if a system-level vulnerability has been exploited — dropping the gate at the tenant level ensures that no data can be accessed while you investigate. This provides maximum containment during the critical early hours of an incident. If a regulatory body, law enforcement agency, or legal team requires you to immediately halt all access to encrypted data — for example, in response to a subpoena, a data preservation order, or a compliance audit finding — the tenant-level gate provides an auditable, instant lockdown that covers all data in the tenant. If you are aware of a security incident but do not yet know its scope — for example, you've detected anomalous activity but are unsure which users or policies are affected — dropping the tenant gate provides comprehensive protection while you determine the extent of the breach. You can then selectively restore access as you clear individual users and policies. If the infrastructure supporting your Theodosian deployment (network, identity provider, cloud accounts) has been compromised, dropping the tenant gate prevents any attacker who may have gained access to user credentials from accessing encrypted data. ## Choosing the Right Gate Level Before dropping the gate at the tenant level, consider whether a more targeted approach would be appropriate: | Scenario | Recommended action | | ------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------- | | A single user's account is compromised | [Drop the gate on the user](/help/command/anomalous-activity/drop-the-gate-on-users) | | A specific category of sensitive files may be at risk | [Drop the gate on the protection policy](/help/command/anomalous-activity/drop-the-gate-on-protection-policies) | | Multiple users or policies are affected, but not the entire tenant | Drop the gate on each affected user and/or policy individually | | The scope is unknown or the entire tenant may be compromised | Drop the gate on the tenant | | A regulatory or legal order requires total data lockdown | Drop the gate on the tenant | ## Troubleshooting The **Drop the Gate on Tenant** setting is only visible on the [Tenant Security](/help/command/tenant/tenant-security) page, and only to users who are members of the **Global Administrator** security group. If you do not see this setting, check your security group membership or ask a Global Administrator to perform the action on your behalf. Check whether the gate has also been dropped at the user or policy level: * **User level** — Check the user's profile under the **Drop the Gate** tab, or look for the red **Gate Dropped** badge next to their name in the [user list](/help/command/users/manage-users). Individual user gates must be removed separately. * **Policy level** — Check the protection policy's **Drop the Gate** tab, or look for the **Gate Dropped** badge in the [protection policies list](/help/command/protection-policies/overview). Individual policy gates must be removed separately. You can immediately remove the gate by toggling the **Drop the Gate on Tenant** switch back to the off position on the [Tenant Security](/help/command/tenant/tenant-security) page. Access will be restored immediately for all users and policies (unless they have their own individual gates active). A compliance audit event will be logged for both the drop and the removal, providing a full record of what occurred. This is expected behavior. Dropping the tenant gate blocks access to encrypted data, but it does not stop [encryption automation rules](/help/command/data-connectors/encryption-automations) from running. New files will continue to be encrypted and assigned to protection policies. They will simply be inaccessible until the gate is removed. If you want to stop automation rules from running entirely, you can [delete the rules](/help/command/data-connectors/encryption-automations) or [remove the cloud connections](/help/command/data-connectors/connecting-a-provider) that power them. This is by design. The tenant-level gate blocks access to encrypted **data**, but it does not prevent users from signing in to Theodosian Command or using the web panel. Users can still manage their profiles, view settings, and perform administrative tasks — they simply cannot access any encrypted file content. If you need to fully lock a specific user out of Theodosian (including sign-in), [drop the gate on that user individually](/help/command/anomalous-activity/drop-the-gate-on-users). There is no automated recommendation for when to remove the gate — this is a judgment call based on your investigation. Before removing the tenant gate, ensure that: * The root cause of the security incident has been identified and resolved. * Any compromised user accounts have been individually locked out with [user-level gates](/help/command/anomalous-activity/drop-the-gate-on-users). * Any affected protection policies have been reviewed and, if needed, have their own [policy-level gates](/help/command/anomalous-activity/drop-the-gate-on-protection-policies) applied for continued targeted lockdown. * Your security team has confirmed that it is safe to restore access. * You have reviewed the [compliance audit log](/help/command/compliance/audit-log) for any suspicious activity during the incident. # Drop the Gate on Users Source: https://theodosian.com/help/command/anomalous-activity/drop-the-gate-on-users Immediately revoke a user's access to all encrypted data across your tenant. Drop the Gate on a user is an emergency security action that immediately locks a specific user out of Theodosian. When you drop the gate on a user, all of their active sessions are terminated, they are prevented from signing back in, and they receive an email notification informing them that their access has been revoked. This is designed for situations where you suspect a user's account has been compromised, a user is behaving maliciously, or you need to immediately revoke someone's access for any reason while you investigate. You must have the **User Management** permission to drop the gate on a user. By default, users in the **Global Administrator** security group have this permission. ## What Happens When You Drop the Gate on a User When the gate is dropped on a user, the following occurs immediately: 1. **All active sessions are terminated** — The user is signed out of every device and browser session, including the desktop app and Theodosian Command. 2. **Sign-in is blocked** — The user cannot sign back in to Theodosian until the gate is removed. 3. **All access is revoked** — The user cannot access any encrypted files, protection policies, or Theodosian features. 4. **Email notification is sent** — The user receives an email informing them that the gate has been dropped on their account. 5. **Compliance event is logged** — A compliance audit event is recorded for tracking and accountability purposes. Dropping the gate on a user is an aggressive action that completely locks them out of all Theodosian functionality. The user will not be able to access any encrypted files — even files they created — until the gate is removed. Use this only when you have a genuine security concern. ## Restrictions The following restrictions apply to dropping the gate on users: | Restriction | Description | | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Cannot drop the gate on yourself** | You cannot drop the gate on your own account. This prevents accidental self-lockout. | | **Cannot drop the gate on Global Administrators** | Users who are members of the **Global Administrator** security group are protected from having the gate dropped on them. | | **Only visible for other users** | The **Drop the Gate** tab only appears on user profiles that are not your own. | ## Dropping the Gate on a User In the sidebar, click **Users** to open the User Management page. Find the user you want to lock out in the user list and click on their row to open their profile page. On the user's profile page, click the **Drop the Gate** tab. This tab is only visible when viewing another user's profile — it does not appear on your own. Toggle the **Drop the Gate** switch to the on position. A confirmation dialog will appear. Review the confirmation message carefully: > *"Please confirm you want to drop the gate on this user. This will sign the user out of all current sessions, and disable all use of the Theodosian product while the gate has been dropped. This will also email the user to inform them the gate has been dropped on their account."* Click **Proceed** to confirm. The gate will be dropped immediately. You will see a success notification confirming that the gate has been dropped and the user has been signed out of all sessions and notified via email. ## Removing the Gate from a User When the security concern has been resolved and you are ready to restore the user's access, you can remove the gate. Removing the gate does not require a confirmation dialog. In the sidebar, click **Users**, then click on the user whose gate you want to remove. Click the **Drop the Gate** tab on the user's profile page. Toggle the **Drop the Gate** switch to the off position. The gate will be removed immediately. You will see a success notification confirming that the gate has been removed and the user can now access Theodosian. Removing the gate does **not** automatically restore the user's previous sessions. The user will need to sign in again after the gate is removed. Any sessions that were active before the gate was dropped are permanently terminated. ## Identifying Users with a Dropped Gate When the gate has been dropped on a user, a red **Gate Dropped** badge appears next to their name across Theodosian Command. This badge is visible in the following locations: | Location | Description | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------ | | **User Management list** | The badge appears next to the user's name in the main user table. | | **User profile page** | The badge appears next to the user's display name at the top of their profile. | | **Security group member lists** | The badge appears next to the user's name in any security group they belong to. | | **Protection policy member lists** | The badge appears next to the user's name in any protection policy they are a member of. | | **Member selection dropdowns** | The badge appears next to the user's name when selecting members for security groups or protection policies. | The badge looks like this: a red shield icon with the text **Gate Dropped** in red, making it immediately visible wherever the user appears in the interface. ## Relationship to Other Gate Levels Drop the Gate operates at three levels in Theodosian — users, protection policies, and the entire tenant. These levels are independent but can overlap: | Level | Scope | Effect on the user | | ---------------------------------------------------------------------------------------------- | ------------------------ | --------------------------------------------------------------------------------------------------------------------------- | | **User** | Individual user | The specific user is locked out of all Theodosian functionality. Other users are unaffected. | | **[Protection Policy](/help/command/anomalous-activity/drop-the-gate-on-protection-policies)** | All files under a policy | All users are blocked from accessing files under the specific policy. The user can still access files under other policies. | | **[Tenant](/help/command/anomalous-activity/drop-the-gate-on-tenant)** | Entire tenant | All users in the tenant are blocked from accessing any encrypted data. | If the gate is dropped on a user **and** on a protection policy or tenant, removing the user-level gate will not restore their access to data that is also locked at the policy or tenant level. Each gate level must be removed independently. ## Use Cases If you receive an alert or notice suspicious activity on a user's account — such as sign-ins from unexpected locations, unusual file access patterns, or reports from the user that their credentials may be compromised — drop the gate immediately to prevent any further access while you investigate. When an employee leaves the organization and you need to immediately revoke all access to encrypted data, drop the gate on their account. This ensures they are signed out of all devices instantly, rather than waiting for their sessions to expire naturally. You can then [remove the user](/help/command/users/manage-users) from the tenant at your convenience. If a user is found to be violating data handling policies — such as sharing encrypted files inappropriately or accessing data they should not — drop the gate to immediately halt their access while you review the situation and determine next steps. If you are investigating a broader security incident and want to proactively lock out specific users as a precaution while you assess the scope of the issue, dropping the gate on those users provides an immediate, reversible lockout without deleting their accounts. ## Troubleshooting The **Drop the Gate** tab is only visible when viewing another user's profile — it does not appear on your own profile. Additionally, you must have the **User Management** permission. If you are viewing another user's profile and still do not see the tab, check your security group membership to confirm you have the required permission. You cannot drop the gate on users who are members of the **Global Administrator** security group, and you cannot drop the gate on yourself. If the user is a Global Administrator, you will need to remove them from the Global Administrator group first (if appropriate) before dropping the gate. After removing the gate, the user must sign in again — their previous sessions are not restored. Ask the user to go through the normal [sign-in process](/help/command/account/signing-in). If they still cannot sign in, verify that: * The gate has been fully removed (check the toggle on the user's **Drop the Gate** tab). * The tenant-level gate is not also active, which would block all users regardless of individual gate status. * The user's account has not been separately [removed from the tenant](/help/command/users/manage-users). You can immediately remove the gate by toggling the switch back to the off position on the user's **Drop the Gate** tab. The user will regain access to Theodosian right away, though they will need to sign in again since their sessions were terminated. A compliance audit event will be logged for both the drop and the removal, providing a full record of what occurred. When the gate is dropped, an email notification is automatically sent to the user. If the user did not receive the email, ask them to check their spam or junk folder. The email is sent to the email address associated with their Theodosian account. Currently, Drop the Gate is applied to users one at a time through each user's profile page. To lock out multiple users simultaneously, you would need to repeat the process for each user. If you need to block access for all users at once, consider [dropping the gate on the entire tenant](/help/command/anomalous-activity/drop-the-gate-on-tenant) instead. # Billing Management Source: https://theodosian.com/help/command/billing/billing-management View your subscription status, access the billing portal, and manage your plan. The Billing Management page gives you visibility into your tenant's subscription status, upcoming renewal dates, and due amounts. From here, you can also access the Stripe billing portal to update payment methods, view invoices, and manage your subscription. You must have the **Billing** permission to access the Billing Management page. By default, users in the **Global Administrator** security group have this permission. ## Accessing Billing Management Click **Settings** at the bottom of the sidebar navigation. In the Settings sidebar under the **Tenant** heading, click **Billing**. The Billing Management page will load with your current subscription information. ## Page Overview The Billing Management page displays different content depending on whether your tenant has an active subscription. ### If You Have No Subscription If your tenant does not have an active subscription, the page displays a message indicating that no active subscriptions are found, along with a **Setup Billing** button. Clicking this button will take you through the billing setup and checkout flow to select a plan and enter payment details. This typically only applies to newly created tenants that have not yet completed the billing setup step during [tenant creation](/help/command/tenant/creating-a-tenant). Most tenants will have an active subscription or trial. ### If You Have an Active Subscription When your tenant has an active subscription, the page displays a **Manage Billing** button and a subscription summary card with the following information: | Field | Description | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Subscription Status** | The current state of your subscription, displayed as a status badge. See [Subscription Statuses](#subscription-statuses) below. | | **Renewal Date** | The date your subscription will next renew and billing will occur. This is only shown when an upcoming invoice exists. | | **Due Amount** | The amount that will be charged on the renewal date, displayed in your subscription's currency (e.g., \$49.00 USD). This is only shown when an upcoming invoice exists. | If your subscription renewal has been canceled, the renewal date and due amount are replaced with a notice indicating when your subscription and service will cease. ## Subscription Statuses Your subscription status reflects the current state of your billing relationship with Theodosian: | Status | Description | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Active** | Your subscription is current and in good standing. You have full access to all Theodosian features included in your plan. | | **Trialing** | You are in a free trial period. Full access to Theodosian features is available. When the trial ends, your payment method will be charged automatically unless you cancel before the trial period expires. | | **Past Due** | A payment has failed. Your subscription is still active, but you should update your payment method through the billing portal to avoid service interruption. | | **Canceled** | Your subscription has been canceled. Access to Theodosian features will continue until the end of the current billing period, after which service will cease. | ## Free Trial When your tenant is on a free trial, a trial notification box appears in the sidebar showing how much time remains before the trial ends. The remaining time is displayed as: * **Days** — when more than 48 hours remain (e.g., "Trial ends in 14 days") * **Hours** — when less than 48 hours remain (e.g., "Trial ends in 23 hours") The trial notification is visible across all pages in Theodosian Command, keeping you informed of how much evaluation time remains. During the trial period, your tenant has full access to all Theodosian features. No charges are applied until the trial ends. If you decide not to continue, cancel your subscription through the billing portal before the trial expires to avoid being charged. ## Managing Your Billing To update payment methods, view invoices, or make changes to your subscription, use the Stripe billing portal. Go to **Settings → Tenant → Billing** to open the Billing Management page. Click the **Manage Billing** button in the top-right corner of the page. You will be redirected to the Stripe billing portal. In the Stripe billing portal, you can: * **Update your payment method** — Add, remove, or change the credit card or payment method on file. * **View invoices** — Access your complete invoice history, including past payments and upcoming charges. * **Cancel your subscription** — Stop automatic renewal at the end of the current billing period. * **Manage your plan** — View your current plan details and billing cycle. When you are finished, use the link in the portal to return to Theodosian Command. The billing portal is hosted by [Stripe](https://stripe.com), Theodosian's payment processor. All payment information is handled securely by Stripe — Theodosian never stores your credit card details or other sensitive payment data. ## Setting Up Billing for the First Time If your tenant does not have an active subscription — for example, if billing was not completed during [tenant creation](/help/command/tenant/creating-a-tenant) — you can set it up from the Billing Management page. Go to **Settings → Tenant → Billing** to open the Billing Management page. Click the **Setup Billing** button. You will be taken to the plan selection and checkout flow. You will be directed to a secure Stripe checkout page where you can review the subscription plan and enter your payment details. If a free trial is available, the trial duration will be displayed so you know how long you can evaluate the platform before charges begin. Fill in your billing information and confirm the subscription. Once payment is confirmed, you will be redirected back to the Billing Management page, which will now display your active subscription details. ## Subscription Cancellation If you cancel your subscription through the Stripe billing portal, the following occurs: * Your subscription status remains **Active** until the end of the current billing period. * The Billing Management page will display a notice indicating that subscription renewal has been canceled and the date when service will cease. * The renewal date and due amount fields are replaced by the cancellation notice. * After the current billing period ends, access to Theodosian features will be restricted. Canceling your subscription does **not** immediately revoke access. Your tenant and all its data remain available until the end of the current billing period. However, once service ceases, users will no longer be able to access encrypted files or use Theodosian features. ## Billing and User Count Each provisioned user in your tenant counts toward your subscription's seat allocation. As you [invite new users](/help/command/users/provision-users) or [remove existing users](/help/command/users/manage-users), your usage is updated accordingly. The due amount shown on the Billing Management page reflects your current user count and billing cycle. Review your user count periodically to ensure you are not paying for users who no longer need access. You can view and manage your current users on the [User Management](/help/command/users/manage-users) page. ## Troubleshooting The **Billing** link in the Settings sidebar is visible to all users, but the Billing Management page itself requires the **Billing** permission. If you see an access denied message when you click Billing, check your [security group membership](/help/command/users/security-groups) to confirm you have the Billing permission. If you do not, ask a Global Administrator to either grant you the permission or manage billing on your behalf. This can occur if the Stripe checkout session did not complete successfully. Click the **Setup Billing** button to go through the checkout flow again. If you believe you already completed payment, check your email for a Stripe receipt and contact [support](https://theodosian.com/support) with the transaction details. A **Past Due** status means a payment attempt has failed — typically because the credit card on file has expired, been declined, or has insufficient funds. Click **Manage Billing** to open the Stripe billing portal and update your payment method. Stripe will automatically retry the payment once a valid payment method is on file. Plan changes are managed through the Stripe billing portal. Click **Manage Billing** on the Billing Management page to access the portal, where you can view available plan options and switch plans. Any prorated charges or credits will be applied automatically. If you recently canceled and want to resubscribe, click **Manage Billing** to open the Stripe billing portal. Depending on where you are in the billing period, you may be able to reactivate your subscription directly from the portal. If the option is not available, contact [support](https://theodosian.com/support) for assistance. The billing portal is hosted by Stripe and requires an active internet connection. If the page does not load, check your network connection and try again. If your browser blocks the redirect, try disabling any ad blockers or popup blockers that may be interfering. You can also try a different browser. The trial notification box only appears when your subscription status is **Trialing** and the trial has not yet expired. If your trial has ended and transitioned to an active paid subscription, the notification will no longer be displayed. You can confirm your current subscription status on the Billing Management page. The due amount displayed on the Billing Management page reflects your upcoming invoice based on your current plan and user count. If the amount looks unexpected, check whether users have been recently added or removed. For a detailed breakdown, click **Manage Billing** to view the full invoice in the Stripe billing portal. # Audit Log Source: https://theodosian.com/help/command/compliance/audit-log Search, filter, and review compliance events across your tenant. The Audit Log is a centralized record of every compliance-relevant action that occurs within your tenant. Every sign-in, file access, policy change, gate drop, encryption event, and administrative action is captured as a compliance event and stored in the Audit Log for review, investigation, and regulatory accountability. The Audit Log is accessible from the **Compliance** section of the sidebar and provides a searchable, filterable table of all compliance events, along with detailed views for individual events. You must have the **Compliance** permission to access the Audit Log. By default, users in the **Global Administrator** security group have this permission. ## Accessing the Audit Log In the sidebar, under the **Compliance** heading, click **Audit Log**. The Audit Log page loads with a table displaying the most recent compliance events across your tenant. ## The Compliance Events Table The main Audit Log page displays a paginated data table listing compliance events in reverse chronological order (newest first). Each row in the table represents a single compliance event and displays the following columns: | Column | Description | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Event ID** | The unique identifier for the compliance event. | | **Time** | The date and time the event occurred, displayed in the format "15 Jun 2025 at 2:30 PM." | | **Location** | The geographic location of the user or system that triggered the event, displayed as "City, Region, Country." | | **IP Address** | The IP address from which the event originated. | | **Event Type** | A color-coded badge identifying the specific action that occurred (e.g., "User Sign In," "File Decrypted," "Policy Created"). See [Event Categories](#event-categories) below. | | **Event Category** | The broad category the event belongs to (e.g., "Authentication," "File," "Security"). | | **Actions** | A **Full Details** button that navigates to the full event detail view. | Events are displayed 50 per page. Use the pagination controls at the bottom of the table to navigate between pages. The total count of compliance events matching your current filters is displayed next to the pagination controls. You can also click on any row in the table to open the full detail view for that event. ## Event Categories Every compliance event is classified into a category that describes the area of the system it relates to. Categories are visually distinguished by color-coded badges with icons, making it easy to scan the Audit Log and identify the type of activity at a glance. The following event categories are used throughout the Audit Log: | Category | Description | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **User** | Events related to individual user actions, such as signing in, profile updates, and MFA changes. | | **Tenant** | Events related to tenant-level administration, such as tenant configuration changes and tenant-wide settings updates. | | **System** | Events triggered by system or API-level operations. | | **Device** | Events related to device registration, removal, and session management. | | **Security** | Events related to security group management, permission changes, and security-related actions. | | **Protection Policy** | Events related to protection policy creation, updates, member management, and access control configuration. | | **File** | Events related to file-level operations, such as file encryption, decryption, and access attempts. | | **System Configuration** | Events related to system-level configuration changes and managed updates. | | **Encryption** | Events related to encryption key management and encryption operations. | | **Cloud Connectors** | Events related to data connector connections, encryption automations, and cloud storage operations. | | **Gate** | Events related to [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-users) actions at the user, protection policy, and tenant levels. | | **Approval** | Events related to [Email Approvals](/help/command/protection-policies/email-approvals) — request creation, individual recipient votes, and final resolutions (approved, denied, timed out, cancelled, or pool insufficient). | Each event type within a category has a specific description (e.g., "User Sign In," "Protection Policy Created," "Gate Dropped on User") that provides more detail about exactly what occurred. ## Filtering Events The Audit Log includes a powerful filtering system that allows you to narrow down the events displayed in the table. Click the **Filters** button above the table to open the filter menu and add one or more filters. ### Available Filters Filters are organized into the following groups: **Event Type** — Filter by specific event types (e.g., "User Sign In," "File Decrypted," "Policy Created"). This is a searchable list — type to find the event type you are looking for, then select it to add it as a filter. You can select multiple event types. **Security Group** — Filter events associated with a specific security group. Search for a security group by name and select it. * **User: Target** — Filter by the user who was the target of an action (e.g., the user whose gate was dropped, the user who was invited). Search by name or email. * **User: Actioned** — Filter by the user who performed the action (e.g., the administrator who dropped the gate, the user who signed in). Search by name or email. * **Location: IP** — Filter by a specific IP address. Type the IP address directly. * **Location: City** — Filter by city name. Type the city name directly. * **Location: Region** — Filter by region or state name. Type the region name directly. * **Location: Country** — Filter by country. Search from the list of available countries and select one. **Protection Policy** — Filter events associated with a specific protection policy. Search for a policy by name and select it. * **Device: OS** — Filter by operating system (e.g., Windows, macOS). Search from the list of available operating systems and select one. * **Device: Type** — Filter by device type (Desktop or Web). * **Device: Serial Number** — Filter by a specific device serial number. Type the serial number directly. **Date Range** — Filter events within a specific date range by selecting a start date and end date using the date picker. **FileID** — Filter events associated with a specific file by entering its file identifier directly. ### Applying and Removing Filters Click the **Filters** button above the compliance events table. Choose a filter from the dropdown menu. The filter will be added to the active filters bar below the Filters button. Click on the filter chip in the active filters bar to open its configuration popover. Depending on the filter type, you can search and select values, type values directly, or choose a date range. The table automatically updates to show only events matching your active filters. The total event count updates to reflect the filtered results. You can add multiple filters — they are applied together (AND logic), so only events matching all active filters are displayed. Click the **×** button on any filter chip in the active filters bar to remove it. The table will update immediately. Combine filters for precise investigations. For example, to review all file access failures from a specific user in a given date range, apply the **Event Type** filter for failed access events, the **User: Target** filter for the specific user, and the **Date Range** filter for the time period of interest. ## Viewing Event Details To see the full details of a compliance event, click on any row in the table or click the **Full Details** button in the row's Actions column. The event detail page displays all available information about the event, organized into the following sections: ### Event Overview | Field | Description | | ------------------ | --------------------------------------------------------------------------------------------------- | | **Event ID** | The unique identifier of the compliance event. | | **Time** | The date and time the event occurred. | | **Event Type** | The specific event type, displayed as a color-coded badge (e.g., "User Sign In," "File Decrypted"). | | **Event Category** | The broad category the event belongs to (e.g., "Authentication," "File"). | | **Event Code ID** | The internal event code identifier used by the system. | ### Location Information | Field | Description | | -------------- | --------------------------------------------------------------------- | | **IP Address** | The IP address from which the event originated. | | **City** | The city associated with the IP address. | | **Region** | The region or state associated with the IP address. | | **Country** | The country associated with the IP address. | | **Lat/Long** | The approximate latitude and longitude coordinates of the IP address. | ### Device Details | Field | Description | | ------------------------ | --------------------------------------------------------------- | | **Device Name** | The name of the device that generated the event (if available). | | **Device Serial Number** | The serial number of the device (if available). | | **Device Type** | The type of device (e.g., Desktop, Web). | | **Device OS** | The operating system of the device (if available). | ### User Details | Field | Description | | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Source User ID** | The ID of the user who performed the action. | | **Target User ID** | The ID of the user who was the target of the action (if applicable). For self-initiated actions (like signing in), this may be the same as the source user or empty. | ### Additional Details Some events include additional context-specific information beyond the standard fields. When present, this section displays any extra metadata and parsed payload data associated with the event. The fields shown here vary depending on the event type — for example, a file access event may include the file identifier, while a policy change event may include the policy name and what was changed. ## Common Use Cases When you suspect unauthorized access or a security breach, use the Audit Log to trace the sequence of events. Apply the **User: Target** filter for the affected user, the **Date Range** filter for the relevant time period, and review all events chronologically. Look for unusual sign-in locations, failed access attempts, or unexpected administrative actions. Cross-reference findings with the [Dashboard Analytics](/help/command/compliance/dashboard-analytics) for broader access trends. After [dropping the gate](/help/command/anomalous-activity/drop-the-gate-on-users) on a user, protection policy, or tenant, confirm the action was recorded by filtering the Audit Log for **Gate** category events. The event detail will show who performed the gate drop, when it occurred, and which user, policy, or tenant was affected. To generate an audit trail for a specific file or set of files, use the **FileID** filter to isolate all events related to a particular file. You can also combine this with the **Date Range** filter to scope the audit to a specific reporting period. Each event will show who accessed the file, when, from where, and on what device. When a protection policy includes an [Email Approvals](/help/command/protection-policies/email-approvals) block, the Audit Log records the full lifecycle of each approval request: creation, every individual recipient vote, and the final resolution. Filter by **Event Type** for `Approval Request Resolved - Approved` (or any of the denial variants) to find the outcomes of past approval requests, and follow back through the related vote events to see which recipients approved, denied, or did not respond. This is the canonical place to look for the approval history once a request has aged out of the 7-day approvals page window. To review all administrative actions performed in your tenant — such as policy creation, user provisioning, security group changes, or tenant configuration updates — filter by the relevant event categories (e.g., **Protection Policy**, **Security**, **Tenant**). This provides a clear timeline of who made what changes and when. If you need to review all activity originating from a specific IP address, city, region, or country, use the **Location** filters. This is useful for identifying access from unexpected geographies or verifying that access controls are working as intended. To see everything a particular user has done (or had done to them), apply the **User: Actioned** filter to see events they performed, or the **User: Target** filter to see events where they were the subject of an action. Combine with the **Date Range** filter to scope the review. ## Troubleshooting The **Audit Log** link appears under the **Compliance** heading in the sidebar. If you do not see it, you may not have the **Compliance** permission. Check your [security group membership](/help/command/users/security-groups) to confirm you have the required permission, or ask a Global Administrator to grant it. If the Audit Log is empty, your tenant may be newly created and no compliance-relevant actions have been recorded yet. Events are generated automatically as users sign in, access files, change settings, and perform other actions. Once activity begins in your tenant, events will appear in the Audit Log. When multiple filters are active, they are applied using AND logic — only events matching **all** active filters are shown. If your filters are too restrictive, try removing one or more to broaden the results. Also verify that the filter values you entered are correct (e.g., check for typos in IP addresses or city names). Not all compliance events have values for every field. For example, system-generated events may not have device information, and self-initiated actions may not have a target user. A dash (—) indicates that the field is not applicable or the data was not available for that specific event. Try broadening your filters or removing them entirely to search the full event history. If you know the approximate date, apply a **Date Range** filter to narrow the time window. If you know the event ID, you can navigate directly to it by appending the event ID to the compliance URL in your browser. The Audit Log captures all compliance-relevant actions across the tenant, including automated events such as file access checks, system-level operations, and encryption automation activity. High event counts are normal in active tenants — it means the system is comprehensively tracking all activity for compliance purposes. Use the **Export** button in the top-right of the Audit Log to export the events matching your current filters, or open a single event and export it on its own. Exports can be generated as PDF, CSV, or JSON and are delivered to the [Compliance Exports](/help/command/compliance/compliance-exports) page. See [Compliance Exports](/help/command/compliance/compliance-exports) for the full workflow. # Compliance Exports Source: https://theodosian.com/help/command/compliance/compliance-exports Export compliance audit events to PDF, CSV, or JSON, then download them from a dedicated exports page. Compliance Exports let you take a snapshot of your [Audit Log](/help/command/compliance/audit-log) — either a filtered set of events or a single event — and generate a downloadable file in PDF, CSV, or JSON format. Exports are useful for sharing an audit trail with external auditors, archiving evidence for a reporting period, or reviewing events outside of Theodosian Command. Exports are generated in the background. When an export is ready, the requester receives an email and the file becomes available on the **Compliance Exports** page. Each export is itself recorded in the Audit Log, so both requesting and downloading an export leave their own compliance events. You must have the **Compliance Logs Export** permission to request and download exports. By default, users in the **Global Administrator** security group have this permission. Without it, the **Export** button is disabled and the **Compliance Exports** entry in the sidebar appears locked and can't be opened. ## Starting an Export You can start an export from two places: * **The Audit Log** — exports all events matching the filters currently applied to the table. * **An event's detail page** — exports that single compliance event. In both cases, click the **Export** button in the top-right of the page to open the **Export Audit Log** dialog, then follow the two steps below. Choose **PDF**, **CSV**, or **JSON**. Each format lists the maximum number of events it supports — see [Export Formats](#export-formats) below. Review what will be exported, then click **Request Export**. For a filtered export, this step shows the number of events, the estimated file size, the estimated time to generate, and a summary of the applied filters. If the selection is larger than the chosen format allows, a warning appears and you must pick a different format or narrow your filters before continuing. For a single event, this step simply confirms that one compliance event will be exported in the chosen format. After you confirm, the export is queued and you'll receive an email when it's ready to download. You can close the dialog and keep working — there's no need to wait on the page. ## Export Formats | Format | Best for | Maximum events | | -------- | ----------------------------------------------------------------- | -------------- | | **PDF** | A formatted, human-readable report for sharing or archiving. | 10,000 | | **CSV** | Opening in Excel or Google Sheets, or importing into other tools. | 1,000,000 | | **JSON** | Programmatic processing and integration with other systems. | 100,000 | If a filtered export exceeds the limit for a format, choose a format with a higher limit (CSV supports the most events) or apply additional filters in the Audit Log to reduce the number of events before exporting. ## Finding Your Exports Completed exports live on the **Compliance Exports** page, accessible from the **Compliance** section of the sidebar. The page has two tabs: * **All Exports** — every export requested across your tenant. * **My Exports** — only the exports you requested. Each tab shows a paginated table (50 per page) with the following columns: | Column | Description | | ---------------- | ---------------------------------------------------------------------------------------- | | **File Name** | The name of the export file. | | **Format** | The export format (**PDF**, **CSV**, or **JSON**). | | **Status** | The current state of the export: **Pending**, **Running**, **Completed**, or **Failed**. | | **Size** | The size of the downloadable file. | | **Exported At** | The date and time the export was requested. | | **Requested By** | The user who requested the export. | When an export is **Completed** and has not expired, a **Download** button appears on its row. Click it to download the file, which is delivered as a `.zip` archive containing your export. Click any row to open the export's detail page. ## Export Details Clicking an export opens its detail page, which is shareable with other administrators who have the **Compliance Logs Export** permission. It is organized into the following sections: ### Overview The file name, format, size, status, expiry date, and the user who requested the export. If an export failed, the reason is shown here as well. ### Timeline When the export was requested, when generation started, and when it completed. ### Scope What the export covers. For a single-event export, this links directly to the [event's detail page](/help/command/compliance/audit-log#viewing-event-details). For a filtered export, it lists the search term and each applied filter, or notes that no filters were applied and all events were included. ## Retention and Expiry Exports are retained for **30 days**. After that, the file is permanently deleted and can no longer be downloaded — the export record remains visible on the **Compliance Exports** page, but its **Download** button is disabled and marked as expired. If you need the data again after an export has expired, request a new export. ## Common Use Cases Apply the filters that scope the events your auditor needs — for example, a **Date Range** for the reporting period and the relevant **Event Type** or **FileID** filters — then export to **PDF** for a formatted report or **CSV** for raw data they can analyze. Share the downloaded file directly. When a specific event needs to be preserved on its own — for instance, a notable access attempt or administrative action — open the event from the Audit Log and export it individually. This produces a standalone record of just that event. Export to **JSON** for programmatic processing or **CSV** for spreadsheet tools. Use the format's higher event limits to capture large date ranges in a single export. ## Troubleshooting If the **Compliance Exports** entry under the **Compliance** heading appears locked (greyed out with a padlock), you don't have the **Compliance Logs Export** permission. Check your [security group membership](/help/command/users/security-groups) to confirm you have it, or ask a Global Administrator to grant it. The **Export** button is disabled when you lack the **Compliance Logs Export** permission. Hovering over it shows a tooltip explaining this. Contact a Global Administrator to request the permission. If generation fails, the export's status becomes **Failed** and you receive an email with a brief reason. The most common cause is a selection larger than the chosen format allows — narrow your filters or choose a format with a higher limit (see [Export Formats](#export-formats)) and request the export again. The **Download** button is only available for exports that are **Completed** and have not yet expired. If the export is still **Pending** or **Running**, wait for the email confirming it's ready. If it has passed its 30-day retention window, it is expired and must be requested again. # Dashboard Analytics Source: https://theodosian.com/help/command/compliance/dashboard-analytics Monitor file access analytics, tenant-wide statistics, and compliance trends from the dashboard. The Dashboard is the first page you see when you sign in to Theodosian Command. It provides a real-time overview of your tenant's compliance posture, including the total volume of protected data, file access activity, and key tenant metrics — all presented through summary cards and interactive charts covering the last 28 days. The Dashboard is available to all authenticated users. However, some metrics — such as the subscription renewal date — link to pages that require additional permissions (e.g., the **Billing** permission to access [Billing Management](/help/command/billing/billing-management)). ## Accessing the Dashboard Click **Dashboard** at the top of the sidebar navigation. The Dashboard loads automatically when you first sign in to Theodosian Command. ## Page Layout The Dashboard is organized into three rows of information: 1. **Top row** — Tenant Overview summary card and Protected Data trend chart (side by side). 2. **Middle row** — Three cards showing today's access statistics: Access Passed, Access Pass Rate, and Access Failed. 3. **Bottom row** — Two bar charts showing Access Passed and Access Failed trends over 28 days. ## Tenant Overview The **Tenant Overview** card is displayed in the top-left of the Dashboard and provides a snapshot of your tenant's current state. It includes the following metrics: | Metric | Description | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Total protected files** | The total number of files currently encrypted and protected across the entire tenant. | | **Users in tenant** | The total number of provisioned users in your tenant. | | **Security groups** | The total number of [security groups](/help/command/users/security-groups) configured in the tenant. | | **Data protection policies** | The total number of [protection policies](/help/command/protection-policies/overview) configured in the tenant. | | **Next renewal** | The date of your next subscription renewal. This links to the [Billing Management](/help/command/billing/billing-management) page for users with billing permissions. If no active subscription exists, this displays "No active subscription." | ## Protected Data Chart The **Protected Data (28 days)** chart is displayed in the top-right of the Dashboard. It is an area chart that shows the cumulative total of protected files over the last 28 days, giving you a visual trend of how your encrypted data footprint is growing or changing over time. * The **X-axis** represents dates over the 28-day period. * The **Y-axis** represents the cumulative total number of protected files. * A **percentage change indicator** is displayed in the top-right corner of the chart header, showing the percentage increase or decrease in total protected files over the 28-day period (e.g., "Up by 12.50%"). Hover over any point on the chart to see the exact file count for that date. A steadily rising protected data trend indicates that new files are consistently being encrypted — either manually by users via the [desktop app](/help/desktop/daily-use/encrypting-files) or automatically via [encryption automations](/help/command/data-connectors/encryption-automations). A flat or declining trend may indicate that encryption activity has slowed or that files have been removed from protection. ## Today's Access Statistics The middle row of the Dashboard displays three cards summarizing file access activity for the current day: ### Access Passed (Today) Displays the total number of **successful** file access attempts recorded today. A successful access attempt means a user requested access to an encrypted file and was granted access based on the applicable [access controls](/help/command/protection-policies/access-controls). ### Access Pass Rate Displays the **percentage of successful access attempts** relative to the total number of access attempts (both passed and failed) for the current day. For example, if 95 out of 100 access attempts were successful, the pass rate is displayed as **95.00%**. If no access attempts have been recorded today, this card displays a dash (**—**) with the message "No access attempts today." A consistently high access pass rate (close to 100%) indicates that users are accessing files within the boundaries of your configured access controls. A noticeable drop in the pass rate may warrant investigation — it could indicate misconfigured access controls, users attempting to access files they are not authorized for, or potentially suspicious activity. ### Access Failed (Today) Displays the total number of **failed** file access attempts recorded today. A failed access attempt means a user requested access to an encrypted file but was denied based on the applicable [access controls](/help/command/protection-policies/access-controls) — for example, because the user was outside of an approved geographic region, using an unauthorized device, or the [gate was dropped](/help/command/anomalous-activity/drop-the-gate-on-users) on their account. ## 28-Day Access Trend Charts The bottom row of the Dashboard displays two bar charts showing access attempt trends over the last 28 days: ### Access Passed (28 Days) A bar chart showing the number of **successful** file access attempts per day over the last 28 days. Each bar represents one day, and hovering over a bar displays the exact count for that date. ### Access Failed (28 Days) A bar chart showing the number of **failed** file access attempts per day over the last 28 days. Each bar represents one day, and hovering over a bar displays the exact count for that date. Use these charts to identify patterns in access activity. For example, a sudden spike in failed access attempts on a specific day may correlate with a security event, a policy change, or an [anomalous activity](/help/command/anomalous-activity/drop-the-gate-on-users) response. Cross-reference spikes with the [Audit Log](/help/command/compliance/audit-log) to investigate specific events. ## Subscription Alerts The Dashboard displays alert banners at the top of the page when there are billing issues that require attention: | Alert | Description | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **No Active Subscription Found** | A red alert banner appears if your tenant does not have an active subscription. The message prompts you to verify your billing information. Navigate to [Billing Management](/help/command/billing/billing-management) to set up or restore your subscription. | | **Past Due Subscription** | A yellow warning banner appears if your subscription has a failed payment. The banner includes an **Update Billing** button that links directly to the [Billing Management](/help/command/billing/billing-management) page. This alert is only visible to users who have the **Billing** permission. | ## Data Sources The Dashboard pulls data from two compliance analytics endpoints: | Data Source | What It Provides | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Compliance Stats** | Historical file access data (total files, successful access attempts, failed access attempts) aggregated by day over the requested period. Used for all charts and today's access cards. | | **Tenant Stats** | Tenant-level aggregate counts — total users, security groups, and protection policies. Used for the Tenant Overview card. | Data is fetched automatically when the Dashboard loads and reflects the most recently available analytics. Charts display data for the most recent 28 days by default. ## Troubleshooting If the Dashboard displays no data, your tenant may be newly created and may not yet have any encrypted files or file access activity. Data will begin to appear once files are encrypted (either manually through the [desktop app](/help/desktop/daily-use/encrypting-files) or automatically via [encryption automations](/help/command/data-connectors/encryption-automations)) and users begin accessing them. A flat chart means the total number of protected files has not changed over the 28-day period. This can happen if no new files have been encrypted and no existing files have had their encryption removed. It does not necessarily indicate a problem — if your data protection footprint is stable, a flat chart is expected. The Access Pass Rate only displays a percentage when at least one access attempt has been recorded for the current day. If no access attempts have occurred yet today, the card displays a dash (—) and the message "No access attempts today." This is normal, especially early in the day or in tenants with low activity. Subscription status alerts are based on real-time data from the billing system. If you see an alert that does not match your expectations, navigate to [Billing Management](/help/command/billing/billing-management) and click **Manage Billing** to open the Stripe billing portal and verify your payment status. If the issue persists, contact [support](https://theodosian.com/support). The **Update Billing** button on the past due alert is only visible to users who have the **Billing** permission in their [security group](/help/command/users/security-groups). If you do not have this permission, you will still see the alert text but not the action button. Contact a Global Administrator to resolve the billing issue or to grant you the Billing permission. The Dashboard fetches analytics data covering the last 28 days when the page loads. If your tenant has a large volume of file activity, this may take a moment. A loading spinner is displayed while data is being retrieved. If loading consistently takes a long time or fails, check your network connection and try refreshing the page. The percentage change is calculated by comparing the current cumulative total of protected files to the total at the beginning of the 28-day period. If there were very few protected files at the start of the period, even a small increase can result in a large percentage change. This is mathematically correct even if the visual appearance of the chart suggests a modest change. # Connecting a Provider Source: https://theodosian.com/help/command/data-connectors/connecting-a-provider Authorize Theodosian to access your cloud storage providers so you can automate file encryption. Before you can create encryption automation rules, you need to establish a connection between Theodosian and your cloud storage provider. Each connection is authenticated through a secure OAuth flow — you authorize Theodosian directly through your provider's consent screen, and Theodosian never stores your cloud provider password. This page covers how to view, add, re-establish, and remove cloud provider connections. You must be a member of the **Global Administrator** security group to manage data connectors. If you do not see **Data Connectors** in the sidebar, contact your tenant administrator. ## How Connections Work When you connect a cloud storage provider, the following happens: 1. You select a provider from the list of available integrations (e.g., Google Drive, OneDrive, SharePoint). 2. Theodosian redirects you to the provider's OAuth consent screen, where you sign in and authorize access. 3. Once authorized, the provider redirects you back to Theodosian Command, and the connection is established. 4. Theodosian can now access the drives and folders within that provider to discover and encrypt files based on your [encryption automation rules](/help/command/data-connectors/encryption-automations). You can only have **one active connection per cloud provider**. If all available providers already have connections, the new connection screen will inform you that no additional providers are available. To switch accounts for a provider, delete the existing connection first. ## Viewing Your Connections In the sidebar, click **Data Connectors** to open the connections page. If you have existing connections, they are displayed in a table. If you have no connections yet, you will see an empty state prompting you to create your first connection. The connections table displays the following information for each connection: | Column | Description | | -------------------- | --------------------------------------------------------------------------------- | | **Cloud Provider** | The provider's icon and name (e.g., Google Drive, OneDrive, SharePoint). | | **Status** | The current health of the connection — **Connected**, **Inactive**, or **Error**. | | **Associated Rules** | The number of encryption automation rules linked to this connection. | | **Created At** | The date and time the connection was originally established. | | **Updated At** | The date and time the connection was last modified or refreshed. | | **Actions** | Buttons to re-establish or delete the connection. | ## Connection Statuses Each connection has a status indicator that reflects its current health: | Status | Indicator | Description | | ------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Connected** | 🟢 Green | The connection is active and functioning normally. Theodosian can access the provider's drives and encrypt files. | | **Inactive** | 🟡 Yellow | The connection exists but is not currently active. This may occur if the provider's authorization has not been fully completed. | | **Error** | 🔴 Red | The connection has encountered a problem. This typically means the OAuth authorization has expired, been revoked, or the provider is experiencing issues. You should re-establish the connection. | ## Adding a New Connection In the sidebar, click **Data Connectors** to open the connections page. Click the **Add a Cloud Connection** button in the top-right corner of the page. If you have no connections yet, you can also click the **Create your first connection** button in the empty state. You will be taken to the provider selection screen. The provider selection screen displays all available cloud storage providers as cards, each showing the provider's icon, name, and a brief description. Only providers that do not already have an active connection are shown. If all providers are connected, you will see a message indicating that all available providers already have connections. Click on the provider you want to connect. You will be redirected to the cloud provider's OAuth consent screen. Sign in with the account you want to connect and grant Theodosian the requested permissions. The specific permissions requested depend on the provider, but generally include the ability to read and write files in your cloud storage. After authorizing, the provider will redirect you back to Theodosian Command. Your new connection will appear in the connections table with a **Connected** status. You are now ready to [create encryption automation rules](/help/command/data-connectors/encryption-automations) for this provider. Use a service account or shared administrative account when authorizing the connection, rather than a personal account. This ensures the connection remains active even if an individual user leaves the organization or changes their cloud provider password. ## Re-establishing a Connection If a connection's status changes to **Error** or **Inactive** — for example, because the OAuth token has expired or been revoked — you can re-establish it without deleting and recreating the connection. Re-establishing preserves all encryption rules associated with the connection. In the sidebar, click **Data Connectors** to open the connections page. Locate the connection with the **Error** or **Inactive** status in the connections table. In the **Actions** column, click the **Re-establish Connection** button (the refresh icon). You will be redirected to the cloud provider's OAuth consent screen to re-authorize Theodosian. Sign in and grant permissions on the provider's consent screen. You will be redirected back to Theodosian Command, and the connection status should return to **Connected**. ## Deleting a Connection If you no longer need a connection, you can delete it. Deleting a connection is permanent and cannot be undone. When you delete a connection, **all encryption automation rules associated with that connection are also deleted**. Files that have already been encrypted will remain encrypted, but no new files will be processed. Make sure you no longer need the associated rules before proceeding. In the sidebar, click **Data Connectors** to open the connections page. Locate the connection you want to remove in the connections table. In the **Actions** column, click the **Delete** button (the trash icon). A confirmation dialog will appear warning you that associated rules will also be removed. Review the warning and click **Confirm** to permanently delete the connection and all of its associated encryption rules. You will see a confirmation notification once the connection has been removed. ## What Happens After Connecting Once you have an active connection, you can: Define rules to automatically encrypt files in the connected provider's drives and folders. Track the real-time status of files being encrypted by your automation rules. ## Troubleshooting If the provider selection screen shows a message that all available providers already have connections, this means every supported provider is already connected. You can only have one connection per provider. If you need to connect a different account for the same provider, delete the existing connection first, then create a new one. Make sure you are signing in with an account that has administrative access to the cloud storage provider. Some providers require specific admin consent for third-party applications. If your organization restricts third-party app access, contact your cloud provider administrator to approve Theodosian. This can happen if the authorizing account's password changes, MFA is reset, or if an administrator revokes third-party app access in the cloud provider's admin console. Re-establish the connection and ensure the authorizing account has stable, long-lived credentials. Consider using a dedicated service account. Deleting a connection permanently removes all associated encryption rules. Files that were already encrypted remain encrypted and are still governed by their assigned protection policies. To resume automated encryption, create a new connection to the same provider and set up new encryption rules. This may happen if the authorizing account does not have access to any drives or document libraries in the connected provider. Verify that the account used during OAuth authorization has the necessary permissions to access shared drives, team sites, or document libraries in your cloud storage provider. # Data Connectors Source: https://theodosian.com/help/command/data-connectors/data-connectors Connect your cloud storage providers to Theodosian for automated encryption and data protection. Data connectors allow you to integrate your organization's cloud storage providers with Theodosian, enabling automated encryption of files stored in the cloud. Instead of manually encrypting files one by one through the desktop app, data connectors continuously monitor your connected cloud drives and automatically encrypt files based on rules you define. Data connectors are only accessible to users in the **Global Administrator** security group. If you do not see the Data Connectors option in the sidebar, contact your tenant administrator. ## How Data Connectors Work Data connectors bridge the gap between your cloud storage and Theodosian's encryption engine. The process works in three stages: 1. **Connect** — You authorize Theodosian to access a cloud storage provider (such as Google Drive, OneDrive, or SharePoint) through a secure OAuth flow. This creates a *connection* that allows Theodosian to read and write files on your behalf. 2. **Automate** — You create *encryption automation rules* that define which files should be encrypted. Each rule targets a specific drive, folder path, and optionally specific file types. You can also assign a [protection policy](/help/command/protection-policies/overview) to the rule, so encrypted files are automatically governed by the access controls you have configured. 3. **Monitor** — As Theodosian processes files, you can monitor the progress of encryption workloads in real time. Each file moves through a lifecycle from discovery to completed encryption, with live status updates and progress tracking. ## Navigating Data Connectors The Data Connectors section is organized into three pages, each accessible from the sidebar: View and manage your cloud provider connections. Add new providers or remove existing ones. Create and manage rules that automatically encrypt files in your connected cloud storage. Monitor the status and progress of your active encryption jobs. ## Supported Cloud Providers Theodosian supports connections to major cloud storage platforms. The list of available providers is displayed when you create a new connection and may expand over time as new integrations are added. Each provider is connected through a secure OAuth authorization flow — Theodosian never stores your cloud provider password. You can only have **one active connection per cloud provider**. For example, you cannot connect two separate Google Drive accounts simultaneously. If you need to switch accounts, delete the existing connection first and create a new one. ## Key Concepts | Concept | Description | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Connection** | An authorized link between Theodosian and a cloud storage provider. Connections are authenticated via OAuth and can have a status of Active, Inactive, or Error. | | **Drive** | A storage location within a connected provider (e.g., a shared drive in Google Drive or a document library in SharePoint). Each encryption rule targets a specific drive. | | **Encryption Rule** | A definition that tells Theodosian which files to encrypt. Rules specify a drive, folder path, optional file type filters, and an optional protection policy. | | **Protection Policy** | An optional association that governs who can access files encrypted by a rule. If assigned, encrypted files inherit the policy's access controls and membership. | | **Encryption Workload** | The process of encrypting a file. Each workload tracks the file's name, size, progress, and status as it moves through the encryption pipeline. | ## Prerequisites Before setting up data connectors, ensure the following: * You are a member of the **Global Administrator** security group. * You have administrative access to the cloud storage provider you want to connect (you will need to authorize Theodosian through the provider's OAuth consent screen). * If you plan to assign protection policies to your encryption rules, [create the protection policies](/help/command/protection-policies/creating-a-policy) first. ## Getting Started Navigate to **Data Connectors** in the sidebar and [add your first cloud connection](/help/command/data-connectors/connecting-a-provider). You will be redirected to your cloud provider's authorization page to grant Theodosian access. Navigate to **Encryption Automations** in the sidebar and [create your first rule](/help/command/data-connectors/encryption-automations). Select a drive, specify a folder path and file types, and optionally assign a protection policy. Once your rule is active, Theodosian will begin discovering and encrypting files. You can [monitor the progress](/help/command/data-connectors/encryption-workloads) of each file in real time from the Encryption Automations page. ## Billing Impact Encrypted files created through data connectors count toward your tenant's usage, just like files encrypted through the desktop app. Monitor your usage on the [Billing Management](/help/command/billing/billing-management) page. ## Troubleshooting The Data Connectors, Encryption Automations, and Encryption Workloads sidebar links are only visible to users in the **Global Administrator** security group. Ask a Global Administrator to verify your group membership or to set up data connectors on your behalf. An error status typically means the OAuth authorization has expired or been revoked. Navigate to the Data Connectors page, find the connection, and click the **Re-establish Connection** button to re-authorize Theodosian with your cloud provider. See [Connecting a Provider](/help/command/data-connectors/connecting-a-provider) for more details. Verify that your connection status is **Active**, your encryption rule is correctly configured with the right drive and path, and that the files in the target folder match any file type filters you have set. Check the [Encryption Automations](/help/command/data-connectors/encryption-automations) page to view the rule's active encryptions and any errors. # Encryption Automations Source: https://theodosian.com/help/command/data-connectors/encryption-automations Create and manage rules that automatically encrypt files in your connected cloud storage. Encryption automations let you define rules that tell Theodosian which files to encrypt across your connected cloud storage providers. Instead of encrypting files individually through the desktop app, automation rules continuously monitor specific drives and folders and encrypt matching files automatically. Each rule targets a specific cloud connection, drive, and folder path. You can optionally filter by file type and assign a [protection policy](/help/command/protection-policies/overview) so that encrypted files are automatically governed by your organization's access controls. You must be a member of the **Global Administrator** security group to manage encryption automations. If you do not see **Encryption Automations** in the sidebar, contact your tenant administrator. ## How Encryption Automations Work When you create an encryption automation rule, Theodosian begins monitoring the specified drive and folder path in your connected cloud storage. The process works as follows: 1. **Discovery** — Theodosian scans the target drive and folder path for files that match the rule's criteria (including any file type filters). 2. **Queuing** — Discovered files are queued for encryption with a **Pending** status. 3. **Encryption** — Files are processed one at a time. Each file moves to **In Progress** status while being encrypted, with a real-time progress percentage. 4. **Completion** — Once encryption finishes, the file is marked as **Completed**. If a protection policy was assigned to the rule, the encrypted file is automatically governed by that policy's access controls and membership. This cycle repeats continuously, so new files added to the monitored folder are automatically discovered and encrypted. Encryption automation status updates are polled in real time. You do not need to refresh the page to see the latest progress — active encryption counts and file statuses update automatically every few seconds. ## Prerequisites Before creating encryption automation rules, ensure the following: * You have at least one **active** [cloud provider connection](/help/command/data-connectors/connecting-a-provider). If you have no connections, you will be prompted to create one first. * If you want encrypted files to be governed by a protection policy, [create the protection policy](/help/command/protection-policies/creating-a-policy) before creating the rule. ## Viewing Your Encryption Rules In the sidebar, click **Encryption Automations** to open the rules page. If you have existing rules, they are displayed in a table. If you have no rules yet, you will see an empty state prompting you to create your first rule. The rules table displays the following information for each rule: | Column | Description | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Rule Name** | The name you assigned to the rule. A pulsing indicator appears next to the name if the rule has active encryptions in progress. | | **Cloud Provider** | The icon of the cloud provider associated with this rule's connection (e.g., Google Drive, OneDrive). | | **Drive Name** | The name of the specific drive or document library being monitored by this rule. | | **Path** | The folder path within the drive that the rule monitors. Displays *(All files)* if no specific path was set, meaning the rule applies to the entire drive. | | **Extensions** | The file type extensions the rule is filtered to (e.g., `.pdf`, `.docx`). Displays *(All files)* if no file type filter was set. | | **Protection Policy** | The name of the protection policy assigned to this rule, displayed as a link to the policy's detail page. Displays a dash (`-`) if no policy is assigned. | | **Last Encrypted** | The date and time of the most recently encrypted file for this rule. Displays a dash (`-`) if no files have been encrypted yet. | | **Active Encryptions** | The count of files currently being encrypted (pending or in progress). Click the count to open the active encryptions panel. Displays a dash (`-`) when there are no active encryptions. | | **Actions** | A menu with options to **Edit** or **Delete** the rule. | ## Creating a New Rule In the sidebar, click **Encryption Automations** to open the rules page. Click the **Add a New Rule** button in the top-right corner of the page. If you have no rules yet, you can also click the button in the empty state. A multi-step modal will open with a sidebar showing the four setup steps. In the **Rule Name** field, enter a descriptive name for the rule. Choose a name that makes it easy to identify the rule's purpose — for example, "ITAR Folder Rules" or "Finance Reports Encryption". The rule name is required. Click **Next** to continue. Select your cloud provider from the list. Once selected, it collapses to a summary card showing the provider's icon, and the list of available drives appears below. Select the drive you want this rule to monitor. Click **Next** to continue. In the **Path** field, optionally enter the folder path within the drive that the rule should monitor. For example: * `/Shared Documents/General` — monitors only the "General" folder inside "Shared Documents" * `/Engineering/Designs` — monitors the "Designs" folder inside "Engineering" * Leave empty — monitors the entire drive (all files at all levels) Use specific folder paths to target only the files that need encryption. Monitoring an entire drive may encrypt files that do not require it. In the **File Types** field, you can optionally specify which file extensions this rule should apply to. Type the extension (e.g., `.pdf`) and press **comma**, **space**, or **Enter** to add it as a badge. Repeat for additional types. Click the **×** on a badge to remove it. Leave empty to encrypt all file types. Click **Next** to continue. Optionally select a protection policy from the searchable list. When assigned, every file encrypted by this rule will automatically be governed by that policy's [access controls](/help/command/protection-policies/access-controls) and [membership](/help/command/protection-policies/managing-members). Click **Create Encryption Rule** to finish. On success, the modal closes and the rules list refreshes. Theodosian will begin discovering and encrypting files that match the rule's criteria. Validation messages appear per step if required fields are missing. ## Editing a Rule You can update a rule's name and protection policy after creation. The drive and folder path cannot be changed after the rule is created — if you need to target a different drive or path, delete the rule and create a new one. In the sidebar, click **Encryption Automations** to open the rules page. Find the rule you want to edit in the table. Click the **⋮** (three dots) menu in the **Actions** column, then select **Edit**. The edit dialog will appear with the rule's current settings. You can modify the following fields: | Field | Editable | Description | | --------------------- | -------- | ------------------------------------------------------------------------------------------- | | **Rule Name** | ✅ Yes | Update the rule's display name. | | **Cloud Provider** | ❌ No | Displayed as read-only. The provider is determined by the connection and cannot be changed. | | **Drive** | ❌ No | Displayed as read-only. The drive cannot be changed after rule creation. | | **Path** | ❌ No | Displayed as read-only. The path cannot be changed after rule creation. | | **Protection Policy** | ✅ Yes | Change or remove the protection policy assigned to the rule. | Click **Save Changes** to apply your updates. You will see a confirmation notification, and the dialog will close. Changing a rule's protection policy only affects files encrypted **after** the change. Files that were already encrypted under the previous policy remain governed by that policy. ## Deleting a Rule If you no longer need an encryption automation rule, you can delete it. Deleting a rule is permanent and cannot be undone. In the sidebar, click **Encryption Automations** to open the rules page. Find the rule you want to delete in the table. Click the **⋮** (three dots) menu in the **Actions** column, then select **Delete**. A confirmation dialog will appear. Review the warning: files associated with this rule will no longer be encrypted automatically, and any current encryption sessions for the rule will be canceled. Click **Confirm** to permanently delete the rule. Deleting a rule does **not** decrypt files that have already been encrypted. Those files remain encrypted and continue to be governed by their assigned protection policy (if any). Only future automatic encryption is stopped. ## Viewing Active Encryptions When a rule is actively encrypting files, you can view the real-time status of each file being processed. There are two ways to open the active encryptions panel: * **Click the active encryptions count** — In the **Active Encryptions** column of the rules table, click the count badge to open the panel for that rule. * **Click a table row** — Click anywhere on a rule's row in the table to open the active encryptions panel. ### The Active Encryptions Panel The active encryptions panel opens as a slide-out sheet on the right side of the screen. It shows all files currently being processed by the selected rule, with live status updates. Each file entry displays: | Field | Description | | ----------------- | ------------------------------------------------------------------------------------------------------------ | | **File Name** | The name of the file being encrypted. | | **File Size** | The size of the file in a human-readable format (e.g., 2.4 MB). | | **Status** | The current encryption status of the file (see [File Encryption Statuses](#file-encryption-statuses) below). | | **Progress** | For files with **Encrypting** status, a progress bar and percentage showing how far along the encryption is. | | **Error Details** | For files with **Failed** or **Max Retries Exceeded** status, the error message describing what went wrong. | ### File Encryption Statuses Each file being processed by an encryption rule moves through the following statuses: | Status | Badge Color | Description | | ------------------------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Pending** | Yellow | The file has been discovered and queued for encryption but has not started processing yet. | | **Encrypting** | Indigo | The file is currently being encrypted. A progress bar shows the completion percentage. | | **Completed** | Green | The file has been successfully encrypted. Completed files appear in the panel briefly (for up to one minute after completion) and then are removed from the active view. | | **Failed** | Red | The encryption attempt failed. The error details are shown, and Theodosian will automatically retry the file. | | **Max Retries Exceeded** | Red | The file has failed encryption multiple times and will not be retried automatically. The error details describe the cause of the persistent failure. | The active encryptions panel updates automatically every few seconds. You do not need to close and reopen it to see the latest status. ## Rule Configuration Best Practices Monitoring an entire drive (leaving the path empty) will encrypt every file on the drive. This can lead to unintended encryption of files that do not need protection. Target specific folders to ensure only the right files are encrypted. If only certain file types need encryption (e.g., PDFs, Word documents, CAD files), add those extensions as file type filters. This prevents Theodosian from encrypting files like images, temporary files, or system files that may not require protection. While protection policies are optional, assigning one ensures that encrypted files are immediately governed by your access controls. Without a protection policy, encrypted files may not have the access restrictions your organization requires. Use clear, descriptive names for your rules — for example, "ITAR Engineering Drawings" or "HR Confidential Documents". This makes it easier to identify and manage rules as your number of automations grows. ## Troubleshooting The button is always available as long as you are on the Encryption Automations page and you are a Global Administrator. If you do not see the page itself, ensure you are a member of the **Global Administrator** security group. If no drives appear in the drive selector, the connection may not have access to any drives or document libraries. Verify that the account used to authorize the cloud connection has permission to access shared drives, team sites, or document libraries in your cloud provider. You may also need to [re-establish the connection](/help/command/data-connectors/connecting-a-provider) if the authorization has expired. Check the following: - The associated cloud connection has an **Active** status. If it shows **Error** or **Inactive**, [re-establish the connection](/help/command/data-connectors/connecting-a-provider). - The folder path is correct and contains files. Remember that an empty path targets the entire drive. - If you have file type filters set, make sure the files in the target folder match the specified extensions. - Check the **Active Encryptions** panel for any files with **Failed** or **Max Retries Exceeded** status, which may indicate a problem with specific files. Files in **Pending** status are queued and waiting to be processed. If files remain in this status for an extended period, it may indicate that the encryption service is processing a large backlog of files from other rules. Files are processed sequentially, so large batches may take time. The status will update automatically once processing begins. This means the file has failed encryption multiple times and will not be retried automatically. Check the error details in the active encryptions panel for the specific cause. Common reasons include the file being too large, the file being locked or in use by another application, or insufficient permissions to access the file in the cloud provider. You may need to resolve the issue in the cloud provider and then delete and recreate the rule to retry the file. Changing a rule's protection policy only affects files encrypted **after** the change. Files that were previously encrypted remain governed by the protection policy that was assigned at the time of their encryption. To change the policy on existing files, you would need to update the policy assignment through the file's protection policy settings. The drive and folder path are locked after a rule is created and cannot be edited. This is by design to ensure consistency in file tracking. If you need to monitor a different drive or path, create a new rule with the desired settings and delete the old one if it is no longer needed. # Encryption Workloads Source: https://theodosian.com/help/command/data-connectors/encryption-workloads Manually dispatch and monitor encryption jobs across your connected cloud storage. Encryption workloads let you manually dispatch encryption jobs across your connected cloud storage. You select a target drive and folder path, configure optional file type filters and a protection policy, and Theodosian processes every matching file — each one becoming a workload that moves through a defined lifecycle, from queued to completed encryption. This page covers how to create and monitor encryption workloads, understand file statuses, and troubleshoot issues with files that fail to encrypt. You must be a member of the **Global Administrator** security group to view encryption workloads. If you do not see **Encryption Workloads** in the sidebar, contact your tenant administrator. ## How Encryption Workloads Work When you dispatch an encryption workload, Theodosian scans the target drive and folder path for files that match your configured criteria. Each matching file becomes an individual workload item that is queued and processed by Theodosian. Before queueing a file, Theodosian performs two safety checks: * **Already encrypted** — Files that already carry the Theodosian encryption suffix are skipped automatically. * **Already queued** — If a file is already being considered by another workload or encryption automation, it will be skipped A workload tracks everything about the file's encryption journey: * **File identity** — The file's name, size, and type. * **Status** — Where the file is in the encryption pipeline (pending, encrypting, completed, or failed). * **Progress** — For files actively being encrypted, a real-time progress percentage. * **Error details** — For files that failed, a description of what went wrong. * **Timing** — When the workload was created, last attempted, and completed. Encryption workload data updates automatically every few seconds through real-time polling. You do not need to refresh the page to see the latest status. ## Viewing Encryption Workloads You can view and monitor your active encryption workloads from the **Encryption Workloads** page. In the sidebar, click **Encryption Workloads** to open the workloads page. Look at the **Active Encryptions** column in the workloads table. Workloads that are currently processing files display a count badge showing the number of files that are pending or in progress. A pulsing dot indicator next to the workload name also signals that files are actively being processed. To view the file-level details of a workload, click the "view files" text in the encryption workloads component The active encryptions panel will open as a slide-out sheet on the right side of the screen. The panel lists every file currently being processed by the selected workload. Each file entry shows the file name, size, encryption status, and — for files actively encrypting — a progress bar with a completion percentage. ## Creating an Encryption Workload On the Encryption Workloads page, click **New Workload** in the top-right corner. If you have no workloads yet, you can also click **Create New Workload** from the empty state. A multi-step modal will open with a sidebar showing the three setup steps. Select your cloud provider from the list. Once selected, it collapses to a summary card showing the provider's icon and a **Change** button if you need to reselect. The list of available drives appears below. Select the drive you want to encrypt files from. Click **Next** to continue. The file browser displays the contents of the selected drive. Click a folder to navigate into it — breadcrumbs at the top of the browser let you navigate back up. Check the box next to each file you want to include in the workload. The encryption summary panel below the file browser shows the total file count, combined size, and estimated encryption time. It updates automatically as you select and deselect files. The summary may briefly show a skeleton loader while it calculates. Click **Next** to continue. Optionally select a protection policy from the searchable list. When assigned, every file encrypted by this workload will automatically be governed by that policy's [access controls](/help/command/protection-policies/access-controls) and [membership](/help/command/protection-policies/managing-members). Click **Create Workload** to finish. On success, the modal closes and the workloads list refreshes. Theodosian will begin processing the selected files immediately. ## Workload Lifecycle Each encryption workload moves through a defined lifecycle as Theodosian processes the file: ```/dev/null/lifecycle.txt#L1-5 theme={null} Discovery → Pending → Encrypting → Completed ↓ Failed → Retry → Encrypting → Completed ↓ Max Retries Exceeded (permanent failure) ``` ### Lifecycle Stages | Stage | Description | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Discovery** | Theodosian scans the target drive and folder path and identifies files that match the configured criteria (path, file types). Discovered files are immediately queued for processing. | | **Pending** | The file has been queued for encryption and is waiting to be processed. Files are processed sequentially, so a file may remain pending while other files ahead of it are being encrypted. | | **Encrypting** | The file is actively being encrypted. A progress bar and percentage are displayed, updating in real time as the encryption progresses. | | **Completed** | The file has been successfully encrypted. If the workload has an assigned [protection policy](/help/command/protection-policies/overview), the encrypted file is now governed by that policy's access controls and membership. Completed files appear briefly in the workloads panel (for up to one minute after completion) and then are removed from the active view. | | **Failed** | The encryption attempt failed due to an error. The error message is displayed alongside the file entry. Theodosian will automatically retry the file. | | **Max Retries Exceeded** | The file has failed encryption multiple times and has exhausted all retry attempts. It will not be retried automatically. The error message describes the persistent failure. | ## File Encryption Statuses The workloads panel displays a color-coded status badge for each file: | Status | Badge Color | Description | | ------------------------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------ | | **Pending** | 🟡 Yellow | Queued for encryption, waiting to be processed. | | **Encrypting** | 🟣 Indigo | Currently being encrypted. A progress bar shows real-time completion percentage. | | **Completed** | 🟢 Green | Successfully encrypted. The file is now protected. | | **Failed** | 🔴 Red | Encryption failed. An automatic retry will be attempted. The error message is shown below the status. | | **Max Retries Exceeded** | 🔴 Red | Permanent failure after multiple retry attempts. The error message is shown below the status. Manual intervention is required. | ## Workload Details Each file entry in the workloads panel provides the following information: | Field | Description | | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **File Name** | The name of the file as it appears in your cloud storage. Long file names are truncated with an ellipsis. | | **File Size** | The size of the file in a human-readable format (e.g., 512 KB, 2.4 MB, 1.1 GB). | | **Status Badge** | A color-coded badge indicating the file's current encryption status. | | **Progress Bar** | Displayed only for files with **Encrypting** status. Shows a visual progress bar and a percentage value (e.g., 47%) indicating how much of the file has been encrypted. | | **Error Message** | Displayed only for files with **Failed** or **Max Retries Exceeded** status. Describes the specific error that caused the failure. | ## Understanding Progress For files in the **Encrypting** status, the progress bar provides a real-time view of the encryption process: * **0%** — Encryption has just started. The file is being read from cloud storage. * **1–99%** — The file is being actively encrypted. The percentage reflects how much of the file content has been processed. * **100%** — Encryption is finishing up. The encrypted file is being written back to cloud storage. The status will change to **Completed** shortly. Progress updates are polled automatically and typically refresh every few seconds. The speed of encryption depends on the file size, your cloud provider's transfer speed, and the current system load. ## Automatic Retries When a file fails to encrypt, Theodosian automatically retries the encryption up to **3 times** using exponential backoff. The retry process works as follows: 1. The file's status changes to **Failed**, and the error message is recorded. 2. Theodosian schedules a retry with an increasing delay based on the number of previous attempts: * After the 1st failure: \~1 minute delay * After the 2nd failure: \~2 minute delay * After the 3rd failure: \~4 minute delay 3. The file moves back to **Pending** and then to **Encrypting** as the retry is processed. 4. If the retry succeeds, the file is marked as **Completed**. 5. If the retry fails again, the process repeats until all 3 retry attempts are exhausted. 6. Once all retries are exhausted, the file is marked as **Max Retries Exceeded** and is not retried further. Theodosian also detects **stale workloads** — files that have been in **Pending** or **Encrypting** status for more than 1 hour without any progress update. These are treated as failed and go through the same retry process. Stale retries count toward the 3-attempt limit. Files marked as **Max Retries Exceeded** require manual investigation. Check the error message for details and resolve the underlying issue in your cloud storage provider before attempting to re-encrypt the file. ## Completed Workload Visibility Completed encryption workloads are shown in the active encryptions panel to confirm that files have been successfully processed. Once done, workloads can be dismissed so they can be removed from the main view. You can confirm that a workload has been actively encrypting files by checking the **Last Encrypted** column in the workloads table, which shows the timestamp of the most recently completed encryption for each workload. ## Monitoring Multiple Workloads Each encryption workload maintains its own set of file-level entries. To monitor activity across multiple workloads: 1. Open the **Encryption Workloads** page. 2. Scan the **Active Encryptions** column to identify which workloads have files being processed. 3. Click into each workload to view its specific file-level details. Workloads with active files display a pulsing indicator next to the workload name, making it easy to spot which jobs are currently processing files at a glance. ## Common Error Scenarios The following table describes common error messages you may encounter in the workloads panel and how to resolve them: | Error | Likely Cause | Resolution | | ------------------ | ---------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | File access denied | The authorizing account does not have permission to read or write the file. | Check file permissions in your cloud storage provider. Ensure the account used to authorize the connection has read and write access. | | File not found | The file was moved or deleted from cloud storage after it was discovered by the workload scan. | No action needed — the file is no longer in the target location. If you still need it encrypted, ensure the file is in the target path and dispatch a new workload. | | File too large | The file exceeds the maximum supported file size of **2 GB** for cloud encryption. | Consider splitting the file into smaller parts or encrypting it manually through the desktop app if supported. | | Connection error | The cloud provider connection has expired or is experiencing issues. | [Re-establish the connection](/help/command/data-connectors/connecting-a-provider) from the Data Connectors page. | | Timeout | The encryption operation took too long, possibly due to a very large file or slow cloud provider response. | The file will be retried automatically. If it continues to time out, check your cloud provider's service status. | ## Troubleshooting If the panel is empty, it means there are no files currently pending, in progress, or recently completed for the selected workload. Verify that: * The associated cloud connection has an **Active** status. * The target drive and folder path contain files that match the configured criteria. * Any file type filters match the files in the target folder. * Files in the folder have not already been encrypted by a previous workload dispatch. Files in **Pending** status are queued and waiting their turn. Encryption processes files sequentially, so if there is a large backlog of files across multiple workloads, pending files may take time to start. If files remain pending for an unusually long period (more than several minutes with no other files actively encrypting), check the connection status and ensure the cloud provider is accessible. If a file repeatedly fails and retries without reaching **Max Retries Exceeded**, there may be a transient issue with the cloud provider or the file itself. Check the error message for details. Common causes include the file being locked by another application, intermittent network issues, or temporary cloud provider outages. The file will eventually reach **Max Retries Exceeded** if the issue persists. These files are not retried automatically and remain unencrypted in your cloud storage. To retry them, resolve the underlying issue described in the error message, then dispatch a new encryption workload targeting the same drive and folder path. The new workload will rediscover the files and attempt encryption again. Note that stale workloads — files that were stuck in **Pending** or **Encrypting** for more than 1 hour — are also included in the 3-attempt retry budget. If a stale workload consumed all retry attempts, the root cause is likely a connectivity or provider issue rather than a problem with the file itself. The progress bar is only displayed for files with the **Encrypting** status. If the file is very small, it may encrypt so quickly that it moves directly from **Pending** to **Completed** between polling intervals, and you may not see the progress bar at all. This is normal behavior. # Overview Source: https://theodosian.com/help/command/legal/overview Understand how tenant-level and user-level legal acceptance works in Theodosian Command. Theodosian may require acceptance of legal agreements before a user can continue into the application. These agreements are evaluated during sign-in and can apply either to the **tenant** or to the **current user**. ## Types of Legal Agreements There are two types of legal acceptance flows in Theodosian Command: ### Tenant-level agreements Tenant-level agreements apply to the tenant as a whole. * **Terms of Service (TOS)** If Terms of Service acceptance is required, only users in the **Global Administrator** security group can complete it. Once one Global Administrator accepts the updated Terms of Service, the requirement is cleared for the entire tenant. See [Terms of Service Acceptance](/help/command/legal/terms-of-service). ### User-level agreements User-level agreements apply to the individual user who is signing in. * **End User License Agreement (EULA)** * **Services Privacy Policy** These agreements are accepted per user. One user's acceptance does not satisfy the requirement for other users. See [EULA and Services Privacy Policy](/help/command/legal/user-agreements). ## Order of Evaluation During sign-in, Theodosian currently evaluates legal acceptance requirements in this order: 1. **Terms of Service (TOS)** — only when required for the selected tenant and only for Global Administrators 2. **End User License Agreement (EULA)** — when required for the current user 3. **Services Privacy Policy** — when required for the current user If a requirement has already been satisfied, that screen is skipped. ## Where These Screens Can Appear You may encounter legal agreement screens in flows such as: * **Creating a tenant** — the founding admin must accept the required agreements before creating the tenant * **Signing in to Command** — depending on tenant and user status * **Signing in to the desktop app** — after email verification, inside the app * **Joining a tenant by invitation** — invited users may need to accept user-level agreements on first login * **Switching tenants** — if the selected tenant or current user still has pending legal acceptance requirements ## Quick Links Learn how tenant-level TOS acceptance and re-acceptance works for Global Administrators. Learn when users are asked to accept user-level agreements during web and desktop sign-in. ## Related Pages * [Creating a Tenant](/help/command/tenant/creating-a-tenant) * [Signing In](/help/command/account/signing-in) * [Switching Tenants](/help/command/tenant/switching-tenants) * [Provision Users](/help/command/users/provision-users) # Terms of Service Acceptance Source: https://theodosian.com/help/command/legal/terms-of-service Understand how Terms of Service acceptance works during tenant creation and when TOS updates require re-acceptance by a Global Administrator. Theodosian requires acceptance of the [Terms of Service](https://theodosian.com/legal/terms-of-service) for every tenant. This happens in two scenarios: when a tenant is first created, and when the Terms of Service are updated and require re-acceptance. ## TOS During Tenant Creation When you [create a tenant](/help/command/tenant/creating-a-tenant), the creation form includes a required **I agree to the Terms of Service (TOS)** checkbox. The user who creates the tenant is automatically recorded as the person who accepted the Terms of Service on behalf of the organization. ## TOS Re-Acceptance When Theodosian updates the Terms of Service, all tenants are reset to a "not accepted" state. A Global Administrator must re-accept the updated terms before the tenant can continue using Theodosian Command. Only users in the **Global Administrator** security group are shown the re-acceptance screen. Non-admin users are never prompted and continue using the platform normally, regardless of whether a Global Administrator has accepted the updated terms. ### Who Needs to Accept * Only **one** Global Administrator needs to accept the updated Terms of Service per tenant. * Once any Global Administrator accepts, the requirement is fulfilled for the entire tenant — other Global Administrators will not be prompted. * Non-admin users are never blocked or prompted, regardless of TOS status. ### What the Re-Acceptance Flow Looks Like Authenticate using your magic link and complete MFA verification if required, as described in [Signing In](/help/command/account/signing-in). If your account is associated with multiple tenants, select the tenant you want to sign in to. If the Terms of Service have been updated and have not yet been accepted for the selected tenant, you will be redirected to a re-acceptance screen. The screen displays a brief message informing you that the Terms of Service have been updated. Check the **I agree to the Terms of Service (TOS)** checkbox. The "Terms of Service (TOS)" label links to the full [Terms of Service](https://theodosian.com/legal/terms-of-service) so you can review the updated terms. Click **Accept and Continue** to proceed. After accepting, you continue through the sign-in flow as normal. If your account also needs to accept the End User License Agreement or Services Privacy Policy, those screens will appear next. Otherwise, you are redirected to the tenant dashboard. The tenant is now in compliance with the updated Terms of Service. ### Multi-Tenant Behavior TOS acceptance is evaluated independently for each tenant. If you belong to multiple tenants: * **Tenant A** may require re-acceptance while **Tenant B** does not — you will only be prompted when signing in to Tenant A. * Switching to a different tenant does not carry over the acceptance status. Each tenant must be accepted separately by one of its Global Administrators. For more information about working with multiple tenants, see [Switching Tenants](/help/command/tenant/switching-tenants). ### Desktop App Users The desktop app uses the browser to verify the magic link, then returns to the app to continue sign-in. If Terms of Service re-acceptance is required, that screen appears **inside the desktop app**. * If you belong to **multiple tenants**, the TOS screen appears after you select a tenant. * If you belong to **a single tenant**, the app continues directly and shows the TOS screen before sign-in completes. * If other user-level legal agreements are still pending, those screens appear after TOS. For user-level agreements that may appear after TOS, see [EULA and Services Privacy Policy](/help/command/legal/user-agreements). ## Frequently Asked Questions No. The re-acceptance screen is only shown to users in the **Global Administrator** security group. If you are not a Global Administrator, you will not see any TOS prompt and your login flow will not be affected. You should not be prompted if another Global Administrator has already accepted the updated Terms of Service for your tenant. If you are still seeing the re-acceptance screen, try signing out and signing back in. If the issue persists, contact [support](https://theodosian.com/support). No. TOS acceptance is per-tenant. Each tenant must be accepted independently by one of its Global Administrators. Global Administrators will continue to be redirected to the re-acceptance screen each time they sign in to the affected tenant. The tenant remains fully functional for non-admin users — only Global Administrators are gated until acceptance is completed. # EULA and Services Privacy Policy Source: https://theodosian.com/help/command/legal/user-agreements Understand when users are prompted to accept the EULA and Services Privacy Policy, what they will see, and how the flow works across web and desktop sign-in. In addition to tenant-level [Terms of Service](/help/command/legal/terms-of-service), Theodosian may require users to accept user-level legal agreements before they can enter the app: * **End User License Agreement (EULA)** * **Services Privacy Policy** These prompts appear only when needed for the current user. ## When You May See These Screens You may be prompted to accept the EULA, the Services Privacy Policy, or both in situations such as: * **Your first sign-in after being invited to a tenant** * **A future sign-in after one of the agreements has been updated and requires acceptance again** These are **user-level** acceptance steps. Unlike Terms of Service, they do not depend on whether you are a Global Administrator. ## How the Legal Acceptance Flow Works After you verify your email and continue the sign-in flow, Theodosian evaluates legal acceptance requirements in this order: 1. **Terms of Service (TOS)** — only when required for the selected tenant and only for Global Administrators 2. **End User License Agreement (EULA)** — when required for the current user 3. **Services Privacy Policy** — when required for the current user If one of these agreements is already accepted, that screen is skipped. ## What You Will See Start the normal sign-in flow using your magic link. If you belong to multiple tenants, select the tenant you want to enter. If your account still needs to accept the EULA or Services Privacy Policy, Theodosian displays the corresponding agreement screen before allowing you to continue. Review the agreement and click the action button to accept it. Theodosian records the acceptance immediately. If another required legal agreement still needs acceptance, the next screen appears automatically. Once all required legal agreements have been accepted, you continue into the application as normal. ## New Users and Invitations When an administrator [invites a user](/help/command/users/provision-users) to a tenant, that user may be prompted to accept the EULA and Services Privacy Policy during their first successful sign-in. This is a normal part of onboarding and does not require any extra action from the administrator beyond sending the invitation. ## Desktop App Users The desktop app uses the browser to verify the magic link, then returns to the app to continue sign-in. If the EULA or Services Privacy Policy must be accepted, those screens appear **inside the desktop app**. * If you belong to **multiple tenants**, the legal agreement screens appear after you select a tenant. * If you belong to **a single tenant**, the app continues directly and shows any required legal screens before sign-in completes. ## Frequently Asked Questions No. Theodosian only shows the agreements that still require acceptance for your account. If you have already accepted one of them, that step is skipped. This usually means your account had not yet accepted one of the required agreements, or one of the agreements was updated and now requires acceptance again. No. Terms of Service is a separate, tenant-level requirement that applies to Global Administrators when needed. The EULA and Services Privacy Policy are user-level acceptance steps that may appear after Terms of Service. See [Terms of Service Acceptance](/help/command/legal/terms-of-service). # Overview Source: https://theodosian.com/help/command/overview Welcome to Theodosian Command — your central web panel for managing tenants, users, protection policies, data connectors, and compliance. Theodosian is a data encryption and access management platform that protects your organization's files with end-to-end encryption, granular access controls, and real-time compliance monitoring. Whether your files live on local machines or in the cloud, Theodosian ensures that only the right people can access them — under the right conditions. **Theodosian Command** is the web-based administration panel where you manage everything: tenants, users, security groups, protection policies, data connectors, and compliance. It's the control center for your entire encryption infrastructure. ## The Theodosian Platform Theodosian is made up of two components that work together to protect your data: The web panel for administrators. Manage tenants, invite users, configure protection policies, connect cloud storage, and monitor compliance — all from your browser. Lightweight apps for macOS and Windows that let users encrypt, open, and manage protected files directly from their desktop. Runs quietly in the background and integrates with your OS. ## Key Capabilities ### Encrypt Everything, Everywhere Theodosian encrypts files into the `.theodosian` format — a portable, encrypted container that can only be opened by authorized users through the Theodosian Desktop App. Files can be encrypted manually by right-clicking on your desktop, or automatically through cloud data connectors that scan and encrypt files across your connected storage providers. ### Protection Policies [Protection policies](/help/command/protection-policies/overview) are the core of Theodosian's access model. Each policy defines **who** can access encrypted files and **how** — through membership rules and conditional access controls. You can require that users meet specific conditions before decrypting a file, such as being in an approved geographic region, using a specific operating system, or having completed MFA verification. ### Security Groups & Permissions [Security groups](/help/command/users/security-groups) let you organize users by role and assign [permissions](/help/command/users/permissions) that control what they can do inside Theodosian Command. Assign groups to protection policies to manage file access at scale — when a user joins a group, they automatically inherit access to every policy the group is a member of. ### Cloud Data Connectors [Data connectors](/help/command/data-connectors/data-connectors) bridge the gap between your cloud storage and Theodosian's encryption engine. Connect providers like Google Drive, OneDrive, or SharePoint, then define automation rules that continuously discover and encrypt files based on folder paths, file types, and protection policies. ### Drop the Gate When something goes wrong, [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-users) gives you an emergency kill switch to instantly revoke access to encrypted data. It operates at three independent levels — [individual users](/help/command/anomalous-activity/drop-the-gate-on-users), [specific protection policies](/help/command/anomalous-activity/drop-the-gate-on-protection-policies), or the [entire tenant](/help/command/anomalous-activity/drop-the-gate-on-tenant) — so you can respond with exactly the right scope. ### Compliance & Audit Logging The [compliance dashboard](/help/command/compliance/dashboard-analytics) gives you real-time visibility into file access activity, including pass/fail trends, protected data growth, and tenant-wide statistics. Every significant action in Theodosian is recorded in the [audit log](/help/command/compliance/audit-log), giving you a complete, tamper-evident trail for regulatory reporting and incident investigation. ### Data Residency Theodosian supports multiple [data residency jurisdictions](/help/command/tenant/tenant-data-residency) — **Global**, **EU**, and **US FedRAMP** — so your encryption keys, user data, and compliance records are stored and processed in the region that meets your regulatory requirements. Jurisdiction is selected at tenant creation and applies to all data within the tenant. ## Quick Start Get up and running with Theodosian in four steps: [Sign up](https://dash.theodosian.com/signup) and create a new tenant. Choose your data residency jurisdiction and set up billing. You'll automatically become the Global Administrator with full permissions. [Create a Tenant →](/help/command/tenant/creating-a-tenant) Add users to your tenant by sending email invitations. Organize them into security groups to control their permissions across Theodosian Command. [Provision Users →](/help/command/users/provision-users) Define who can access your encrypted files and under what conditions. Add security groups and individual users as members, then configure access controls to enforce location, device, and authentication requirements. [Create a Policy →](/help/command/protection-policies/creating-a-policy) Install the [Desktop App](/help/desktop/overview) to encrypt and open files from your machine, or set up [Data Connectors](/help/command/data-connectors/data-connectors) to automatically encrypt files across your cloud storage. ## Passwordless Authentication Theodosian uses **passwordless authentication** for all sign-ins. There are no passwords to create, remember, or rotate. Instead, users verify their identity through a magic link sent to their email address. Tenants can also enforce [multi-factor authentication](/help/command/account/multi-factor-authentication) and support [passkeys](/help/command/account/passkeys) for additional security. ## Secure Your Tenant Once your tenant is set up, we recommend configuring these security settings: Require all users to set up multi-factor authentication before they can access the platform. Set how long user sessions remain valid before requiring re-authentication. Create role-based groups with specific permissions instead of granting everyone Global Administrator access. Add conditional access rules to protection policies to enforce location, device, and identity requirements. ## Explore the Documentation Create and configure tenants, manage data residency, and control tenant-wide settings. Invite users, manage profiles and devices, and organize users into security groups. Define access rules for encrypted files using membership, roles, and conditional access controls. Connect cloud storage providers and automate file encryption with rules and policies. Monitor access trends, review audit logs, and track your organization's compliance posture. Install and use the Theodosian Desktop App on macOS and Windows to work with encrypted files. ## Need Help? If you run into any issues or have questions, reach out to our support team. Get help from the Theodosian team with setup, configuration, or troubleshooting. # Access Control Templates Source: https://theodosian.com/help/command/protection-policies/access-control-templates Get started quickly with pre-built access control templates for common compliance scenarios. Access control templates are pre-built workflows that you can apply to a protection policy's [access controls](/help/command/protection-policies/access-controls) with a single click. Instead of building a workflow from scratch block by block, templates give you a fully configured starting point for common compliance and access restriction scenarios. You must have the **Protection Policies** permission to apply access control templates. By default, users in the **Global Administrator** security group have this permission. ## Why Use Templates? Building access control workflows from scratch gives you maximum flexibility, but for common scenarios — such as restricting file access to users in a specific country — a template gets you up and running in seconds. Templates are especially useful when: * You are setting up a new protection policy and want to enforce location-based restrictions immediately. * You need to comply with export control regulations like ITAR. * You want a known-good starting configuration that you can customize later. Templates create a complete workflow with all blocks pre-configured and connected. After applying a template, you can modify any block, add new blocks, or remove blocks — the template is just a starting point. ## Applying a Template Navigate to **Protection Policies** in the sidebar, click on the policy you want to configure, and click the **Access Controls** tab. This opens the visual [Access Control Editor](/help/command/protection-policies/access-controls). In the top toolbar, click **Templates**. A dialog will appear showing all available templates. Each template card displays a title and a brief description of what it does. Hover over a template to reveal the **Select Template** button, then click it to choose the template. If your policy already has an access control workflow configured, a confirmation dialog will appear: > *Applying the "\[template name]" template will replace your current workflow. You can discard changes later if needed.* Click **Apply Template** to proceed, or **Cancel** to keep your existing workflow. If your policy has no existing workflow, the template is applied immediately without a confirmation prompt. The template's blocks and connections are loaded onto the canvas. Review the workflow to ensure it meets your requirements. You can modify any block's configuration, add new blocks, or remove blocks as needed. Click **Save** in the top toolbar to publish the access control workflow. It takes effect immediately for all file access attempts under this protection policy. Applying a template **replaces** your entire existing workflow. If you have a custom workflow you want to keep, do not apply a template. If you accidentally apply a template over an existing workflow, click **Discard** in the top toolbar before saving to revert to the previously saved version. ## Available Templates Theodosian provides the following built-in access control templates: ### United States Only | Property | Details | | --------------- | ------------------------------------------------------------- | | **Template** | United States Only | | **Description** | Only allow users from the United States to access data. | | **Use case** | General US-based access restrictions, domestic data policies. | **Workflow:** > **Access Attempt** → **Device Country Check (United States)** → ✅ **Allow Access** / ❌ **Deny Access** This template creates a simple two-step workflow: 1. When a user attempts to open a protected file, their device location is checked against the United States. 2. If the user's device is located in the United States, access is granted. 3. If the user's device is located anywhere else, access is denied. **Blocks used:** * Access Attempt (start) * Device Country Check — configured with **United States** * Allow Access (true path) * Deny Access (false path) *** ### ITAR Compliance | Property | Details | | --------------- | --------------------------------------------------------------------------------------------- | | **Template** | ITAR Compliance | | **Description** | Only allow files to be opened inside of the United States. | | **Use case** | Organizations handling data governed by the International Traffic in Arms Regulations (ITAR). | **Workflow:** > **Access Attempt** → **Device Country Check (United States)** → ✅ **Notification Banner** → **Allow Access** / ❌ **Notification Banner** → **Deny Access** This template extends the United States Only template by adding notification banners for both outcomes: 1. When a user attempts to open a protected file, their device location is checked against the United States. 2. If the user **is** in the United States: * A notification banner is displayed with the message: *"Reminder that this data is governed by ITAR controls"* * Access is then granted. 3. If the user is **not** in the United States: * A notification banner is displayed with the message: *"Data access attempt failed"* * Access is denied. **Blocks used:** * Access Attempt (start) * Device Country Check — configured with **United States** * Notification Banner (success path) — text: "Reminder that this data is governed by ITAR controls" * Notification Banner (failure path) — text: "Data access attempt failed" * Allow Access (after success notification) * Deny Access (after failure notification) This template provides a starting point for ITAR compliance. Depending on your organization's requirements, you may want to add additional blocks such as [MFA Verification](/help/command/protection-policies/access-controls#mfa-verification) or [Device Verification](/help/command/protection-policies/access-controls#device-verification) for stronger authentication. You should also configure an [Acceptance Banner](/help/command/protection-policies/access-controls#acceptance-banner) requiring users to acknowledge their ITAR responsibilities before accessing data. *** ### European Union Only | Property | Details | | --------------- | ------------------------------------------------------------------------------------------ | | **Template** | European Union Only | | **Description** | Only allow users from the European Union to access data. | | **Use case** | Organizations subject to GDPR or EU data residency requirements, EU-internal data sharing. | **Workflow:** > **Access Attempt** → **Device Country Check (EU Member States)** → ✅ **Allow Access** / ❌ **Deny Access** This template creates a location check configured with all 27 EU member states: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, and Sweden. 1. When a user attempts to open a protected file, their device location is checked against the full list of EU member states. 2. If the user's device is located in any EU member state, access is granted. 3. If the user's device is located outside the EU, access is denied. **Blocks used:** * Access Attempt (start) * Device Country Check — configured with **all 27 EU member states** * Allow Access (true path) * Deny Access (false path) This template includes EU member states only. It does not include EEA countries (Iceland, Liechtenstein, Norway) or the United Kingdom. If you need to include additional countries, apply the template and then edit the Device Country Check block to add them. *** ### United Kingdom Only | Property | Details | | --------------- | ---------------------------------------------------------- | | **Template** | United Kingdom Only | | **Description** | Only allow users from the United Kingdom to access data. | | **Use case** | UK-specific data policies, UK data residency requirements. | **Workflow:** > **Access Attempt** → **Device Country Check (United Kingdom)** → ✅ **Allow Access** / ❌ **Deny Access** This template works identically to the United States Only template, but configured for the United Kingdom: 1. When a user attempts to open a protected file, their device location is checked against the United Kingdom. 2. If the user's device is located in the United Kingdom, access is granted. 3. If the user's device is located anywhere else, access is denied. **Blocks used:** * Access Attempt (start) * Device Country Check — configured with **United Kingdom** * Allow Access (true path) * Deny Access (false path) ## Templates Summary | Template | Countries | Notifications | Best For | | ----------------------- | ----------------------- | ------------------------------------------------------ | ------------------------------ | | **United States Only** | United States | No | General US access restrictions | | **ITAR Compliance** | United States | Yes — ITAR reminder on success, failure notice on deny | ITAR-regulated data | | **European Union Only** | All 27 EU member states | No | GDPR and EU data residency | | **United Kingdom Only** | United Kingdom | No | UK-specific data policies | ## Customizing Templates After Applying Templates are starting points, not final configurations. After applying a template, you can use the full power of the [Access Control Editor](/help/command/protection-policies/access-controls) to customize the workflow: ### Common Customizations Insert an [MFA Verification](/help/command/protection-policies/access-controls#mfa-verification) block after the country check to require multi-factor authentication in addition to location verification. Insert an [Acceptance Banner](/help/command/protection-policies/access-controls#acceptance-banner) before Allow Access to require users to acknowledge a compliance statement before opening the file. Insert a [Device Verification](/help/command/protection-policies/access-controls#device-verification) block to require security key authentication, ensuring the user is on a trusted device. Edit the Device Country Check block to add or remove countries from the allowed list. For example, add Canada to the United States Only template for North American access. ### Example: Enhancing ITAR with MFA Starting from the ITAR Compliance template, you can add an MFA verification step: Follow the [template application steps](#applying-a-template) to load the ITAR template. Click on the **Notification Banner** block on the success (true) path — the one that shows "Reminder that this data is governed by ITAR controls." In the configuration panel, find the **Next block** section. If the notification banner is currently connected directly to Allow Access, remove that connection and add a new placeholder block. Click the placeholder block and select **MFA Verification** from the block selector. In the MFA Verification block's configuration, connect the **true** path to the **Allow Access** block and the **false** path to the **Deny Access** block. Optionally, enable [response caching](/help/command/protection-policies/access-controls#response-caching) on the MFA Verification block (e.g., cache for 1 hour) to avoid prompting the user on every file access. Click **Save** to publish the enhanced access control workflow. The resulting workflow: > **Access Attempt** → **Country Check (US)** → ✅ **Notification** → **MFA Verification** → ✅ **Allow** / ❌ **Deny** / ❌ **Notification** → **Deny** ## Troubleshooting The **Templates** button is located in the top toolbar of the Access Control Editor, next to the **Editor** button. If you do not see it, ensure you have the **Protection Policies** permission through your [security group](/help/command/users/security-groups) membership. This permission is required to access the editor and its templates. If you haven't saved yet, click **Discard** in the top toolbar to revert to the last saved version of your workflow. If you already saved after applying the template, the previous workflow cannot be recovered — you will need to rebuild it manually. Templates provide a starting configuration. After applying a template, click on the **Device Country Check** block and use the country search filter in the configuration panel to add or remove countries. Save the workflow after making your changes. Location-based access controls rely on IP geolocation. Users connecting through a VPN will be detected based on the VPN server's location, not their physical location. If your organization uses VPNs, consider whether location-based restrictions are appropriate, or add additional verification blocks (such as Device Verification or MFA Verification) to strengthen access controls beyond location alone. The built-in templates cover the most common scenarios. For other countries, apply any country-based template (such as United States Only) and then edit the Device Country Check block to replace the pre-configured country with the country you need. The country search filter provides a comprehensive list of all supported countries. Theodosian does not currently support creating custom templates. However, you can build a workflow in the editor and use it as a reference when configuring access controls on other policies. The built-in templates serve as starting points that you can customize to match your requirements. # Access Controls Source: https://theodosian.com/help/command/protection-policies/access-controls Define and manage access control rules that govern how protected data can be accessed within your protection policies. Access controls let you define conditional rules that users must satisfy before they can open files protected by a policy. Using a visual workflow editor, you chain together condition checks, verification steps, and actions to build a decision tree that evaluates every time a user attempts to access a protected file. Access controls are optional — if a protection policy has no access controls configured, any member of the policy can access its files without additional conditions. When access controls are configured, membership alone is not enough — the user must also pass every condition in the workflow. You must have the **Protection Policies** permission to create or edit access controls. By default, users in the **Global Administrator** security group have this permission. ## How Access Controls Work When a user on the Theodosian desktop app attempts to open an encrypted file, the following process occurs: 1. Theodosian checks whether the user is a **member** of the protection policy attached to the file. 2. If the policy has an access control workflow, Theodosian evaluates the workflow starting from the **Access Attempt** block. 3. The workflow progresses through each block — checking conditions, requesting verifications, and triggering actions — until it reaches a terminal block. 4. If the workflow reaches an **Allow Access** block, the file is decrypted and opened. 5. If the workflow reaches a **Deny Access** block, access is refused. This evaluation happens in real time on every file access attempt. Changes to access controls take effect immediately — there is no delay or propagation period. ## Opening the Access Control Editor In the sidebar, click **Protection Policies** to open the Protection Policies list page. Click on the protection policy whose access controls you want to configure. Click the **Access Controls** tab. You will be automatically redirected to the visual **Access Control Editor**. The editor opens in full-screen mode with a canvas for building your workflow, a configuration panel on the right side, and a toolbar at the top. ## Editor Interface The access control editor has several key areas: ### Top Toolbar The top toolbar contains: | Element | Description | | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | **Editor** | The default mode — build and edit your workflow on the canvas. | | **Templates** | Browse and apply pre-built [access control templates](/help/command/protection-policies/access-control-templates) to get started quickly. | | **Unsaved Edits** | An orange badge that appears when you have changes that have not been saved. | | **Discard** | Revert all unsaved changes back to the last saved version. Only visible when there are unsaved edits. | | **Save** | Publish your current workflow. Only visible when there are unsaved edits. | | **Exit** | Return to the policy details page. Only visible when there are no unsaved changes. | If you attempt to navigate away from the editor with unsaved changes, a confirmation dialog will appear asking whether you want to save or discard your edits. ### Canvas The central canvas is where your workflow is visually represented as a series of connected blocks. You can: * **Pan** the canvas by clicking and dragging (in Pan & Zoom mode) or by holding the middle mouse button. * **Zoom** in and out using the scroll wheel or pinch gesture. * **Select** blocks by clicking on them. * **Select multiple** blocks by switching to Multiple Select mode and dragging a selection box. * **Move** blocks by dragging them to rearrange the layout. * **Connect** blocks by dragging from a source handle to a target handle. ### Bottom Toolbar The bottom toolbar provides interaction mode controls: | Button | Description | | --------------------------------- | ----------------------------------------------------------------------------------------------- | | **Pan & Zoom** (hand icon) | Navigate the canvas by dragging, scrolling to zoom, and double-clicking to zoom in. | | **Multiple Select** (cursor icon) | Click and drag to select multiple blocks at once. Scrolling pans the canvas instead of zooming. | | **Tidy Workflow** (wand icon) | Automatically rearrange all blocks into a clean, organized layout. | ### Configuration Panel The right-side panel displays configuration options for the currently selected block. When no block is selected, it shows an empty state prompting you to select a block to configure it. The panel's contents change depending on the type of block selected — see [Block Types](#block-types) below for details. ## Block Types Blocks are the building elements of your access control workflow. They are organized into four categories: **Conditions**, **Requests**, **Actions**, and **Access**. ### Access Attempt (Start Block) | Property | Details | | --------------- | ------------------------------------------------- | | **Category** | Start | | **Description** | "User wants to open a file" | | **Deletable** | No — every workflow must begin with this block. | | **Outputs** | One — connects to the next block in the workflow. | The Access Attempt block is the entry point for every access control workflow. It is automatically placed on the canvas when you create a new workflow and cannot be deleted. It represents the moment a user attempts to open an encrypted file. **Configuration:** Select the Access Attempt block to see a **Next block** option in the configuration panel. Click **Add placeholder block** to add the next step in your workflow. *** ### Device Country Check (Location) | Property | Details | | --------------- | ------------------------------------------------------------------------------- | | **Category** | Conditions | | **Description** | "Check user is located in country" | | **Outputs** | Two — a **true** path (condition met) and a **false** path (condition not met). | The Device Country Check block evaluates the user's location based on IP geolocation. If the user's device is located in one of the specified countries, the workflow follows the **true** path. Otherwise, it follows the **false** path. **Configuration:** Click on the Device Country Check block on the canvas. In the configuration panel, use the country search filter to find and select one or more countries. The block displays the selected country name (or a count if multiple countries are selected). Use the **Next block (true)** and **Next block (false)** options to connect subsequent blocks for each outcome. Location detection is based on IP geolocation. Users behind a VPN or corporate proxy may be detected as being in the VPN or proxy's location rather than their physical location. *** ### Device OS Check | Property | Details | | --------------- | ------------------------------------------------------------------------------- | | **Category** | Conditions | | **Description** | "Check user is on a specific OS" | | **Outputs** | Two — a **true** path (condition met) and a **false** path (condition not met). | The Device OS Check block evaluates the operating system of the user's device. If the device is running one of the specified operating systems, the workflow follows the **true** path. Otherwise, it follows the **false** path. **Configuration:** Click on the Device OS Check block on the canvas. In the configuration panel, use the OS search filter to find and select one or more operating systems (e.g., macOS, Windows). The block displays the selected OS name (or a count if multiple are selected). Use the **Next block (true)** and **Next block (false)** options to connect subsequent blocks for each outcome. *** ### Anonymous Connections | Property | Details | | --------------- | -------------------------------------------------------------------------------------------------------------- | | **Category** | Conditions | | **Description** | "Deny any connections that match the following" | | **Outputs** | Two — a **true** path (no anonymous connection detected) and a **false** path (anonymous connection detected). | The Anonymous Connections block evaluates the user's IP address against known anonymous connection types using IP intelligence. If the user's connection matches any of the selected types, the workflow follows the **false** path. Otherwise, it follows the **true** path. This block uses a **fail-closed** approach — if the IP lookup fails for any reason (e.g., the IP intelligence service is unreachable or the device has no IP address), access is automatically denied without following either path. **Configuration:** Click on the Anonymous Connections block on the canvas. In the configuration panel, select one or more anonymous connection types using the checkboxes: | Option | Description | | --------- | --------------------------------------------------------------- | | **Proxy** | Connections routed through a proxy server. | | **Relay** | Connections using a relay service (e.g., iCloud Private Relay). | | **Tor** | Connections routed through the Tor network. | | **VPN** | Connections using a VPN service. | At least one option must be selected. The block cannot be saved with no options checked. Use the **Next block (true)** and **Next block (false)** options to connect subsequent blocks for each outcome. Anonymous connection detection is based on IP intelligence data and may not detect all anonymous connections. Detection accuracy depends on the IP intelligence provider's database coverage. *** ### User Nationality | Property | Details | | --------------- | ------------------------------------------------------------------------------- | | **Category** | Conditions | | **Description** | "Check user's nationality" | | **Outputs** | Two — a **true** path (condition met) and a **false** path (condition not met). | The User Nationality block evaluates the nationality stored on the user's profile. If the user's nationality matches one of the selected values, the workflow follows the **true** path. If the nationality does not match any selected value — or if the user has no nationality set ("Not specified") — the workflow follows the **false** path. **Configuration:** Click on the User Nationality block on the canvas. In the configuration panel, use the nationality search filter to find and select one or more nationalities. The block displays the selected nationality name (or a count if multiple nationalities are selected). Use the **Next block (true)** and **Next block (false)** options to connect subsequent blocks for each outcome. It is your organization's responsibility to validate user nationality. Theodosian does not independently verify the nationality value — it checks the stored value on each user's profile. *** ### Allowed IPs | Property | Details | | --------------- | --------------------------------------------------------------------------------------------------- | | **Category** | Conditions | | **Description** | "Check if the requesting IP (v4 or v6) is in the allow list" | | **Outputs** | Two — a **true** path (IP is in the allow list) and a **false** path (IP is not in the allow list). | The Allowed IPs block evaluates the IP address of the incoming connection against a configured allow list. Both IPv4 and IPv6 addresses are supported. If the user's IP matches any entry in the list, the workflow follows the **true** path. Otherwise it follows the **false** path. This is useful for restricting file access to specific networks, such as a corporate office or a VPN exit node. Each entry in the allow list is tagged with one of three types: | Type | Description | Example | | ------------ | --------------------------------------------------------------------- | --------------------------------------------------- | | **Single** | An exact IP address match (v4 or v6). | `203.0.113.42`, `2001:db8::1` | | **Wildcard** | A pattern using `*` or `x` to match any value in an octet or segment. | `192.168.1.*` | | **Range** | A range spanning from one IP address to another, inclusive. | `10.0.0.1-10.0.0.254`, `2001:db8::1-2001:db8::ffff` | **Configuration:** Click on the Allowed IPs block on the canvas. In the configuration panel, type one or more entries into the input area — one per line. Each line is validated individually and tagged as a **single** address, **wildcard** pattern, or **range** (CIDR). Any lines with errors are highlighted before submission. Added entries appear below the input as individual badges showing their type. Click the remove icon on any badge to delete that entry. Use the **Next block (true)** and **Next block (false)** options to connect subsequent blocks for each outcome. IP-based checks rely on the connecting device's visible IP address. Users behind a VPN or NAT gateway will appear as the VPN or gateway's IP rather than their physical device IP. *** ### Allowed Hours | Property | Details | | --------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Category** | Conditions | | **Description** | "Check user is accessing within an allowed time window" | | **Outputs** | Two — a **true** path (the access attempt falls within an allowed window) and a **false** path (it falls outside every window). | The Allowed Hours block restricts file access to specific times of the week. You define a **timezone** and one or more **time windows**, where each window is a set of weekdays plus a start and end time. When a user attempts to open a file, Theodosian takes the time of the request, converts it into the configured timezone, and checks it against your windows. If the request falls within any window, the workflow follows the **true** path. If it falls outside every window, it follows the **false** path. This is useful for limiting access to business hours, maintenance windows, or shift schedules. End times are **inclusive at the minute level** — a window ending at `11:59 PM` covers every second up to `11:59:59 PM`. **Configuration:** Click on the Allowed Hours block on the canvas. In the configuration panel, use the **Timezone** search field to find and select an IANA timezone (e.g., `America/New_York`). Options are grouped by region for scannability. All time windows are evaluated in this timezone. In the **Allowed Hours** section, build a window: * **Days** — Toggle the day pills (`M T W T F S S`) to choose which weekdays the window applies to. Select at least one. * **Start** and **End** — Type a time into each field. The input accepts flexible formats (e.g., `9`, `9am`, `0900`, `5:30 PM`) and normalizes them. The start must be before the end. Click **Add** to add the window to the list. The Add button stays disabled until at least one day is selected and both times are valid. Added windows appear below the input, each showing its days and time range. Click the remove icon on any window to delete it. Use the **Next block (true)** and **Next block (false)** options to connect subsequent blocks for each outcome. **Spanning midnight.** A single window must have its start before its end, so a window cannot wrap past midnight on its own. To allow access across midnight, add two entries — e.g. Friday 10:00 PM–11:59 PM and Saturday 12:00 AM–6:00 AM. End times are inclusive at the minute level, so the two entries abut with no gap. **Daylight savings.** Allowed Hours are evaluated using IANA timezones. Daylight savings transitions are handled automatically — a 9:00 AM window in America/New\_York stays at 9:00 AM local time year-round. *** ### Acceptance Banner | Property | Details | | --------------- | --------------------------------------------------------------------------- | | **Category** | Requests | | **Description** | "User must accept the banner to proceed" | | **Outputs** | Two — a **true** path (user accepted) and a **false** path (user declined). | The Acceptance Banner block displays a custom message on the user's desktop app and requires them to explicitly accept it before proceeding. This is useful for compliance acknowledgements, data handling reminders, or legal notices. **Configuration:** Click on the Acceptance Banner block on the canvas. In the configuration panel, enter your custom acceptance text in the text area (e.g., "This data is governed by ITAR controls. By proceeding, you acknowledge your responsibility to handle this data in compliance with export control regulations."). Click **Update** to save the text. Enable caching to avoid prompting the user repeatedly. See [Response Caching](#response-caching) for details. Use the **Next block (true)** and **Next block (false)** options to define what happens when the user accepts or declines. *** ### Device Verification | Property | Details | | --------------- | ------------------------------------------------------------------------------------------- | | **Category** | Requests | | **Description** | "User must verify their device to proceed" | | **Outputs** | Two — a **true** path (verification successful) and a **false** path (verification failed). | The Device Verification block requires the user to authenticate using a configured security key (passkey) on their profile. If the user does not have a security key configured, access is automatically denied. **Configuration:** Click on the Device Verification block on the canvas. The configuration panel displays a warning: *"This block requires user to have a configured security key on their profile. If no security key is found, access will be denied."* Enable caching to avoid requiring verification on every access attempt. See [Response Caching](#response-caching) for details. Use the **Next block (true)** and **Next block (false)** options to define what happens on successful or failed verification. Before using the Device Verification block, ensure that the relevant users have [passkeys configured](/help/command/account/passkeys) on their profile. Users without a security key will be denied access when they reach this block. *** ### Email Approvals | Property | Details | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | **Category** | Requests | | **Description** | "Pause file access until designated recipients approve via email" | | **Outputs** | Two — a **true** path (configured number of approvals reached) and a **false** path (denied, timed out, cancelled, or no longer reachable). | The Email Approvals block pauses the workflow and sends an email to a configured list of recipients asking them to approve or deny the access attempt. The user trying to open the file sees a waiting window on their desktop while the request is being reviewed. Once the configured number of approvals is reached, the workflow continues down the **true** path; if any recipient denies, the timer expires, the request is cancelled, or the remaining recipients can no longer reach the threshold, it continues down the **false** path. The next block in each path determines what actually happens to the file access attempt. **Configuration:** Click on the Email Approvals block on the canvas. Pick at least one recipient: * **Users** — Searchable multi-select of individual users in your tenant. * **Security Groups** — Searchable multi-select of security groups. All members of the selected groups are added to the recipient list. When the block runs the system combines the selected users and the current members of the selected security groups, removes duplicates, and excludes the user opening the file. Each unique recipient receives exactly one email per approval request. Choose how many recipients must approve before access is granted. Values from **1** to **5**. Choose how long recipients have to vote, in minutes. Values from **1** to **60**. If the timer expires before the required number of approvals is reached, the workflow takes the false path. Enable caching to skip the block on subsequent access attempts after a successful approval. See [Response Caching](#response-caching) for details. Use the **Next block (true)** and **Next block (false)** options to define what happens when the request is approved or denied. **Resolution rules:** The workflow resolves out of an Email Approvals block as soon as any of the following becomes true: | Outcome | Path | | ---------------------------------------------------------------------------------------------------------------------------------------- | ----- | | The configured number of approvals is reached | True | | Any recipient denies | False | | The timer expires before enough approvals are collected | False | | The user opening the file closes the desktop waiting window | False | | The remaining recipients can no longer reach the required number of approvals (e.g. some were removed from a security group mid-request) | False | Recipient membership is re-evaluated **at vote time**, not snapshotted when the email goes out. A user who is removed from a recipient security group after receiving the email will be prevented from voting. If the same user reopens the same file from the same device while an approval request is still pending, the existing request is reused — no duplicate emails are sent. The desktop simply shows the same waiting window again. Approval requests remain viewable in [Theodosian Command](/help/command/protection-policies/email-approvals) for **7 days** after they resolve. After that, the underlying record is removed and the approvals page shows an unavailable state. The resolution and individual votes are preserved in the [compliance audit log](/help/command/compliance/audit-log) and can be looked up there. *** ### MFA Verification | Property | Details | | --------------- | ------------------------------------------------------------------------------------------- | | **Category** | Requests | | **Description** | "User must verify via MFA to proceed" | | **Outputs** | Two — a **true** path (verification successful) and a **false** path (verification failed). | The MFA Verification block requires the user to authenticate via their configured multi-factor authentication method. If the user does not have MFA configured, access is automatically denied. **Configuration:** Click on the MFA Verification block on the canvas. The configuration panel displays a warning: *"This block requires user to have a configured MFA method on their profile. If no MFA method is found, access will be denied."* Enable caching to avoid requiring MFA on every access attempt. See [Response Caching](#response-caching) for details. Use the **Next block (true)** and **Next block (false)** options to define what happens on successful or failed MFA. Before using the MFA Verification block, ensure that the relevant users have [MFA configured](/help/command/account/multi-factor-authentication) on their profile. Consider enabling [MFA enforcement](/help/command/tenant/tenant-security) at the tenant level so all users are required to set up MFA. Users without MFA will be denied access when they reach this block. *** ### Notification Banner | Property | Details | | --------------- | -------------------------------------- | | **Category** | Actions | | **Description** | "Fire a notification on users desktop" | | **Outputs** | One — continues to the next block. | The Notification Banner block displays a custom notification message on the user's desktop app before continuing the workflow. Unlike the Acceptance Banner, the Notification Banner does not require user interaction — it simply shows the message and proceeds to the next block. This is useful for informational reminders or compliance notices. **Configuration:** Click on the Notification Banner block on the canvas. In the configuration panel, enter your custom notification text in the text area (e.g., "Reminder: This data is classified as confidential."). Click **Update** to save the text. Use the **Next block** option to connect the block to the next step in the workflow. *** ### Email Notification | Property | Details | | --------------- | ---------------------------------- | | **Category** | Actions | | **Description** | "Send an email notification" | | **Outputs** | One — continues to the next block. | The Email Notification block sends an email to one or more recipients when the workflow reaches it. Unlike the Notification Banner (which shows a message on the desktop app), this block delivers a full email via the standard Theodosian transactional email template. The email is sent **asynchronously** in the background — it does not delay the access control decision, and the workflow continues to the next block immediately. **Configuration:** Click on the Email Notification block on the canvas. In the configuration panel, add one or more recipients: * **Users** — Use the searchable multi-select to pick individual users from your tenant. * **Security Groups** — Use the searchable multi-select to pick security groups. All members of the selected groups will receive the email. When the block is evaluated, the system compiles the full recipient list by combining all selected users and all members of selected security groups. Duplicates are automatically removed — each unique email address receives the notification only once, even if the same user appears both individually and via a group. Enter the email subject line in the **Subject** field. You can include dynamic variables (see below) to insert context-specific values. Enter the email body content in the **Body** field. You can include dynamic variables to personalize the message with details about the access event. Use the **Next block** option to connect the block to the next step in the workflow. #### Dynamic Variables Both the subject and body fields support the following variables. Variables are replaced with actual values when the email is sent. | Variable | Description | Example Output | | -------------------------- | ------------------------------------------------------------- | ----------------------------------------- | | `{user_name}` | Full name of the user who triggered the access | Joe Bloggs | | `{user_email}` | Email address of the triggering user | [joe@company.com](mailto:joe@company.com) | | `{user_ip}` | IP address of the requesting user | 203.0.113.42 | | `{time}` | Formatted timestamp of the event | Feb 25, 2026 at 4:43 PM | | `{file_name}` | Name of the accessed file or resource | quarterly-report.pdf | | `{protection_policy_name}` | Name of the protection policy that triggered the notification | Finance Team Policy | Emails are sent asynchronously via a background process. Delivery does not delay the access control decision. If email delivery fails (e.g., due to a temporary mail service issue), the workflow still completes normally — the failure does not affect the access outcome. *** ### Allow Access | Property | Details | | --------------- | -------------------------------- | | **Category** | Access (Terminal) | | **Description** | "User is granted access" | | **Outputs** | None — this is a terminal block. | The Allow Access block is a terminal block that grants the user access to the encrypted file. When the workflow reaches this block, the file is decrypted and opened on the user's device. **Configuration:** No configuration is required. You can delete the block from the configuration panel if needed. *** ### Deny Access | Property | Details | | --------------- | -------------------------------- | | **Category** | Access (Terminal) | | **Description** | "User is denied access" | | **Outputs** | None — this is a terminal block. | The Deny Access block is a terminal block that refuses the user access to the encrypted file. The file remains encrypted and the user is informed that access has been denied. **Configuration:** No configuration is required. You can delete the block from the configuration panel if needed. ## Block Categories Summary | Category | Blocks | Behavior | | -------------- | ---------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | **Conditions** | Device Country Check, Device OS Check, Anonymous Connections, User Nationality, Allowed IPs, Allowed Hours | Evaluate a condition and branch into true/false paths. | | **Requests** | Acceptance Banner, Device Verification, Email Approvals, MFA Verification | Prompt the user for an action or verification and branch based on the result. | | **Actions** | Notification Banner, Email Notification | Perform an action (show a notification or send an email) and continue to the next block. | | **Access** | Allow Access, Deny Access | Terminal blocks that end the workflow with an access decision. | ## Response Caching Request blocks (Acceptance Banner, Device Verification, Email Approvals, MFA Verification) support **response caching**. When caching is enabled, the user's response is remembered for a configurable duration. During this period, the user will skip the verification step on subsequent access attempts if they have already provided a valid response. For the Email Approvals block, only successful resolutions (the request was approved) populate the cache — denied, expired, or cancelled outcomes do not. ### Configuring Cache Click on a request block (Acceptance Banner, Device Verification, Email Approvals, or MFA Verification) on the canvas. In the configuration panel, toggle the **Enable Caching** switch to the on position. Enter the cache time and select the time unit from the dropdown: | Unit | Description | | ----------- | ----------------------------------------------------------------- | | **Minutes** | The cached response is valid for the specified number of minutes. | | **Hours** | The cached response is valid for the specified number of hours. | | **Days** | The cached response is valid for the specified number of days. | Caching improves the user experience by reducing repetitive prompts, but shorter cache durations provide stronger security. Choose a duration that balances convenience with your organization's security requirements. For example: * **High-security data:** Cache for 5–15 minutes * **Standard data:** Cache for 1–8 hours * **Low-risk data:** Cache for 1–7 days ## Building a Workflow Here is a step-by-step guide to building an access control workflow from scratch: When you open the editor for a policy with no existing access controls, the canvas shows the **Access Attempt** block connected to an empty **placeholder block**. Click on the placeholder block. The configuration panel on the right will display the **Block Selector** with all available block types organized by category. Click on a block type from the selector to replace the placeholder. For example, click **Location** (Device Country Check) to add a country check as the first step. The configuration panel will update to show the selected block's configuration options. For a Device Country Check, select the countries you want to allow. Condition and request blocks have true and false output paths. In the configuration panel, use the **Next block (true)** and **Next block (false)** options to add placeholder blocks for each branch. Click each placeholder to select its block type (e.g., Allow Access for the true path, Deny Access for the false path). Ensure every path through the workflow terminates with either an **Allow Access** or **Deny Access** block. Blocks with missing connections will show a validation warning. Click **Save** in the top toolbar to publish your access control workflow. It takes effect immediately for all file access attempts under this protection policy. ### Connecting Blocks Manually In addition to using the configuration panel, you can connect blocks directly on the canvas: 1. Hover over a block's output handle (the small circle at the bottom of the block). 2. Click and drag from the handle to the input handle (top circle) of the target block. 3. Release to create the connection. The editor validates connections and prevents invalid links, such as connecting a block to itself. ### Deleting Blocks To delete a block: 1. Select the block by clicking on it. 2. In the configuration panel, click the **Delete** button. Deleting a block also removes all connections to and from that block. The Access Attempt block cannot be deleted. ### Tidying the Layout If your workflow becomes visually cluttered, click the **Tidy Workflow** button (wand icon) in the bottom toolbar. This automatically repositions all blocks into a clean, hierarchical layout. ## Example: Location-Based Access Control Here is an example of a simple access control workflow that restricts access to users in the United States: The workflow begins when a user tries to open a protected file. A country check evaluates whether the user's device is located in the United States. If the user is in the United States, the workflow reaches the Allow Access block and the file is decrypted. If the user is not in the United States, the workflow reaches the Deny Access block and access is refused. The resulting workflow looks like: > **Access Attempt** → **Device Country Check (US)** → ✅ **Allow Access** / ❌ **Deny Access** To build this workflow even faster, use the [United States Only template](/help/command/protection-policies/access-control-templates#united-states-only). ## Saving and Discarding Changes ### Saving Click the **Save** button in the top toolbar to publish your workflow. The editor validates that all blocks are properly connected before saving. If any block has a validation error (e.g., a condition block with no countries selected, or a block that is not connected), the save will indicate which blocks need attention. Saved access controls take effect immediately. The next time a user attempts to access a file under this policy, the updated workflow will be evaluated. ### Discarding Click the **Discard** button to revert all changes back to the last saved version of the workflow. This is useful if you made experimental changes that you don't want to keep. ### Exiting When you have no unsaved changes, click the **Exit** button to return to the policy details page. If you have unsaved changes and attempt to leave, a dialog will prompt you to save or discard before navigating away. ## Troubleshooting The Access Controls tab is available on every protection policy's details page. If you cannot see it, verify that you have the **Protection Policies** permission through your [security group](/help/command/users/security-groups) membership. The tab requires this permission to access the editor. The **Save** button only appears when you have unsaved changes. If you opened the editor but haven't modified anything, the **Exit** button is shown instead. Make a change to the workflow to see the Save and Discard buttons. Validation warnings appear when a block is not properly configured or connected. Common causes include: * **Condition blocks** (Device Country Check, Device OS Check, Anonymous Connections, User Nationality, Allowed IPs) — No countries, operating systems, connection types, nationalities, or IP entries are selected. Open the configuration panel and make a selection. * **Allowed Hours** — The block is invalid if no timezone is selected, if there are no time windows, or if any window has no days selected, a malformed time, or an end time that is not after its start. Open the configuration panel and complete the configuration. * **Notification or Acceptance Banner** — No banner text has been set. Open the configuration panel, enter text, and click **Update**. * **Email Notification** — At least one recipient (user or security group) is required, the subject and body must not be empty, and all `{variable}` placeholders must be from the [supported variables list](#dynamic-variables). Unknown variables produce specific error messages (e.g., "Unknown variable in subject"). All errors are returned at once. * **Disconnected blocks** — A block is not connected to any other block. Use the configuration panel or drag a connection on the canvas to link it. * **Terminal blocks** — An Allow Access or Deny Access block is not connected as a target of any other block. Review the access control workflow to check for conditions the user may not satisfy: * **Device Country Check** — Is the user's detected location correct? VPNs or corporate proxies may affect geolocation detection. * **Device OS Check** — Is the user's operating system included in the allowed list? * **Device Verification** — Does the user have a [passkey](/help/command/account/passkeys) configured? Users without a security key are automatically denied. * **MFA Verification** — Does the user have [MFA](/help/command/account/multi-factor-authentication) configured? Users without MFA are automatically denied. * **Anonymous Connections** — Is the user connecting through a VPN, proxy, Tor, or relay service? This block also denies access if the IP lookup fails (fail-closed behavior). * **User Nationality** — Does the user have a nationality set on their profile? Does it match one of the selected values? Users with no nationality set ("Not specified") are automatically denied. * **Acceptance Banner** — Did the user decline the acceptance banner? * **Allowed IPs** — Is the user's visible IP in the allow list? Users behind a VPN or NAT gateway appear with the gateway's IP, not their device IP. * **Allowed Hours** — Is the user attempting access within one of the configured time windows? Remember the windows are evaluated in the block's configured timezone, not the user's local time — a misconfigured timezone is the most common cause. Also confirm the windows cover the intended period (including the two-entry pattern for ranges that span midnight). Also check whether [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-protection-policies) is active on the policy or on the [user](/help/command/anomalous-activity/drop-the-gate-on-users). Common Allowed Hours misconfigurations: * **Wrong timezone** — Windows are evaluated in the timezone configured on the block, not the user's local time. If users are allowed or denied at the wrong moment, confirm the timezone matches the schedule you intended. * **End before start** — A single window must have its start time before its end time. A window cannot span midnight on its own. To cover a range that crosses midnight, add two windows that meet at midnight (e.g. Friday 10:00 PM–11:59 PM and Saturday 12:00 AM–6:00 AM). * **Missing windows** — A block with a timezone but no time windows is invalid and will show a validation warning on save. Add at least one window. * **A day looks uncovered** — End times are inclusive at the minute level (11:59 PM covers up to 11:59:59 PM), and windows only match the weekdays you select. Verify both the days and the time range on each window. To remove access controls, open the editor and delete all blocks except the Access Attempt block (which cannot be deleted). Then disconnect the Access Attempt block from any remaining blocks. Save the workflow. With no complete path from Access Attempt to an Allow/Deny block, the policy will not enforce any access control conditions and will allow all members to access files. Alternatively, you can delete the protection policy and create a new one without access controls. Click the **Tidy Workflow** button (wand icon) in the bottom toolbar. This automatically rearranges all blocks into a clean, organized layout without changing any connections or configuration. If you applied a template and haven't saved yet, click **Discard** in the top toolbar to revert to the last saved version. If you already saved, the previous workflow cannot be recovered — you will need to rebuild it manually. # Creating a Policy Source: https://theodosian.com/help/command/protection-policies/creating-a-policy Create a new protection policy to control who can access your encrypted files and under what conditions. Creating a protection policy is the first step toward securing your data with Theodosian. A policy defines which users and security groups can access encrypted files, and serves as the container for any [access control rules](/help/command/protection-policies/access-controls) you want to enforce. You must have the **Protection Policies** permission to create protection policies. By default, users in the **Global Administrator** security group have this permission. ## Before You Begin Before creating a protection policy, consider the following: * **Policy name** — Choose a descriptive name that reflects the purpose of the policy (e.g., "ITAR Controlled Data", "Engineering Team Files", "Finance - Confidential"). * **Members** — Decide which security groups and individual users should have access to files protected by this policy. You can add members during creation or later from the [policy details page](/help/command/protection-policies/managing-members). * **Access controls** — Access control rules are configured separately after the policy is created using the [visual editor](/help/command/protection-policies/access-controls). You do not need to set them up during creation. ## Creating a New Protection Policy In the sidebar, click **Protection Policies** to open the Protection Policies list page. Click the **Create New Policy** button in the top-right corner of the page. A multi-step modal will open with a sidebar showing the three setup steps. In the **Policy Name** field, enter a descriptive name for your protection policy. | Field | Description | | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Policy Name** | A human-readable name that identifies the purpose of this policy. This name is visible across Theodosian Command, the desktop app, and audit logs. You can change it later from the [policy details page](/help/command/protection-policies/overview#editing-a-policy-name). | The policy name is required. The **Next** button will remain disabled until a name is entered. Click **Next** to continue. Search and select security groups from the inline list using checkboxes. Use the search bar to filter by group name. The counter shows how many groups are currently selected. All members of the selected security groups will automatically have access to files protected by this policy. If new users are added to those security groups later, they will inherit access as well. Click **Next** to continue. Search and select individual users from the inline list using checkboxes. Use the search bar to find users by name or email. Each entry displays the user's profile picture, name, and email address. The counter shows how many users are currently selected. Click **Create Protection Policy** to finish. On success, the modal closes automatically and the Protection Policies list refreshes to show the new policy. ## Understanding Policy Membership How membership works: * If security groups or individual users are associated with the policy, **only those users or members of those groups** will be able to access the protected files. * If **no groups or individual users** are associated, **all users in the tenant** will be able to access files under this policy. Leaving a policy with no members means every user in your tenant can access its files. If you intend to restrict access, make sure to add at least one security group or individual user during creation, or add members afterwards from the [policy details page](/help/command/protection-policies/managing-members). ### Member Roles When adding members during policy creation, all security groups and individual users are assigned the **Member** role by default. The available roles are: | Role | Description | | ----------------- | ----------------------------------------------------------------------------- | | **Administrator** | Full access to files and the ability to manage the policy. | | **Member** | Access to files protected by the policy, but cannot modify the policy itself. | You can change roles after the policy is created from the policy's [Members management](/help/command/protection-policies/managing-members) page. ## What Happens After Creation After your protection policy is created, it appears in the Protection Policies list and is ready to use. However, it does not protect any files yet — files must be encrypted under the policy through the [desktop app](/help/desktop/daily-use/encrypting-files) or [data connectors](/help/command/data-connectors/encryption-automations). ### Next Steps Add or remove security groups and individual users, and configure their roles within the policy. Build conditional access workflows to enforce location, device, and authentication requirements before granting file access. Apply a pre-built access control template for common compliance scenarios like ITAR or EU-only access. Start encrypting files under your new protection policy using the Theodosian desktop app. ## Example: Creating an ITAR Policy Here is a walkthrough of creating a protection policy for ITAR-controlled data: Click **Create New Policy**, then enter **ITAR Controlled Data** as the policy name. Click **Next**. In the Security Groups step, search for and select the **Engineering** security group using the checkbox. Only members of this group will be able to access ITAR files. Click **Next**. In the Users step, search for and select your compliance officer by name or email using the checkbox. This gives them access to ITAR files independently of their security group membership. Click **Create Protection Policy**. After the modal closes, open the new policy from the list, navigate to the **Access Controls** tab, and apply the [ITAR Compliance template](/help/command/protection-policies/access-control-templates#itar-compliance) to restrict access to users located in the United States. ## Troubleshooting The button is only visible to users who have the **Protection Policies** permission through their [security group](/help/command/users/security-groups) membership. Contact your tenant administrator to request this permission. Check the following: * **The policy name is not empty** — A name is required to create a policy. * **You have a valid session** — If your session has expired, sign in again and retry. * **You have the required permission** — Ensure your security group includes the **Protection Policies** permission. If the error persists, contact [support](https://theodosian.com/support). You can add security groups and individual users at any time after the policy is created. Open the policy from the Protection Policies list, and use the **Security Groups** or **Users** tab to manage membership. See [Managing Members](/help/command/protection-policies/managing-members) for detailed instructions. Theodosian does not currently support duplicating protection policies. To create a similar policy, create a new one and manually configure the same members and access controls. No. Creating a protection policy only defines who can access files and under what conditions. Files must be encrypted under the policy separately — either manually through the [desktop app](/help/desktop/daily-use/encrypting-files) or automatically through [data connectors](/help/command/data-connectors/encryption-automations). # Email Approvals Source: https://theodosian.com/help/command/protection-policies/email-approvals Review and act on file access approval requests in Theodosian Command. When a protection policy includes an [Email Approvals](/help/command/protection-policies/access-controls#email-approvals) block, recipients receive an email asking them to review a file access attempt. Clicking **View Details** in that email opens the approvals page in Theodosian Command, where the recipient can see the request and cast their vote. This page describes what recipients see on the approvals page and how the page behaves during and after the approval lifecycle. ## How Recipients Arrive Here Each approval email contains a **View Details** button that links to the approvals page for a specific request. The URL has the form: ``` https://dash.theodosian.com//approvals/ ``` The `` segment ensures the link opens in the right workspace when a recipient belongs to multiple tenants. If the recipient is not signed in when they click the link, Theodosian Command redirects them through the standard [sign-in flow](/help/command/account/signing-in) and brings them back to the approvals page once authentication completes. ## Page Layout ### Before Voting When a recipient lands on the approvals page for a request that is still pending and they have not yet voted, the page shows: | Element | Description | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Countdown** | A large, live timer showing how long is left before the request expires. | | **Access attempt details** | The requesting user's name, email, IP address, the time of the attempt, the file name, and the protection policy that triggered the approval. | | **Approval counter** | A live "X of Y approvals" tally that updates as other recipients vote. | | **Approve / Deny buttons** | The two actions available to the recipient. Each action is logged with a timestamp. | ### After Voting Once the recipient submits their vote, the Approve/Deny buttons are replaced with a confirmation panel showing the choice they made. The access attempt details remain visible and the countdown continues to run until the request resolves or the timer expires. Votes are locked once submitted. A recipient cannot change their mind after voting. ### After Resolution Once enough recipients have approved, any recipient denies, the timer expires, or the requesting user cancels the request by closing the waiting window on their desktop, the request resolves and the page transitions to a resolved state: * The countdown is replaced with the final outcome (approved or denied). * The decisions and the final tally remain visible for reference. * No further input is accepted. The page stays viewable in this resolved state for **7 days**, so recipients can revisit it to confirm what they decided and to see the final outcome. ## Access Denied The approvals page is only accessible to current recipients of the request. A recipient is considered current if, at the moment they open the page, they: * Are explicitly listed in the block's selected users, **or** * Belong to one of the block's selected security groups. Membership is re-evaluated on every page load and on every vote. If a recipient was removed from a security group after the email was sent, they will see an Access Denied state instead of the approval page. ## No Longer Available After 7 days from the moment the request resolves, the underlying record is removed and the approvals page can no longer display the request. A message explains that the request is no longer available. The resolution and individual votes remain in the [compliance audit log](/help/command/compliance/audit-log) under the events that were emitted at the time. Filter the audit log by date range and event type to locate the corresponding entry. ## Real-Time Updates While a request is pending, the approvals page reacts to state changes without requiring a manual refresh: * The countdown ticks down in real time. * The approval counter increases as other recipients approve. * If another recipient denies, the timer expires, or the requesting user cancels the request while the page is open, the page transitions to the resolved state immediately. ## Related How to add the block to a protection policy's access controls. What the user opening the file sees while recipients are voting. # Managing Members Source: https://theodosian.com/help/command/protection-policies/managing-members Add and remove security groups and individual users from your protection policies to control who can access protected files. Protection policy membership determines who can access files encrypted under a given policy. Members can be added as **security groups** (granting access to all users in the group) or as **individual users**. Each member is assigned a role that controls their level of access within the policy. This page covers how to view, add, update, and remove both security group and individual user members from an existing protection policy. You must have the **Protection Policies** permission to manage policy membership. By default, users in the **Global Administrator** security group have this permission. ## How Membership Works Protection policy membership follows these rules: * **Security groups** — When a security group is added to a policy, every user in that group becomes a member of the policy. If new users are added to the security group later, they automatically inherit access to the policy's files. * **Individual users** — Specific users can be added directly to a policy, independent of any security group. * **No members** — If a policy has no security groups and no individual users assigned, **all users in the tenant** can access files under that policy. A protection policy with no members is effectively open to the entire tenant. If you intend to restrict access, make sure at least one security group or individual user is assigned to the policy. ## Member Roles Each member — whether a security group or an individual user — is assigned a role within the protection policy: | Role | Description | | ----------------- | ----------------------------------------------------------------------------------------- | | **Administrator** | Has full access to files protected by the policy and can manage the policy configuration. | | **Member** | Can access files protected by the policy but cannot modify the policy itself. | By default, new members are added with the **Member** role. ## Accessing Policy Membership In the sidebar, click **Protection Policies** to open the Protection Policies list page. Click on the protection policy whose membership you want to manage. The policy details page will open. The details page has four tabs. Use the **Security Groups** tab to manage group-based membership, or the **Users** tab to manage individual user membership. ## Managing Security Groups The **Security Groups** tab displays all security groups currently assigned to the protection policy. Each row in the table shows: | Column | Description | | ---------- | ------------------------------------------------------------------------------------- | | **Member** | The security group's name, displayed with an avatar. | | **Role** | The role assigned to this security group within the policy (Administrator or Member). | | **Joined** | The date the security group was added to the policy. | ### Adding or Removing Security Groups On the protection policy's details page, ensure the **Security Groups** tab is selected. This is the default tab when you open a policy. Click the **Edit Security Group** button above the table. The table view will be replaced with a security group selection panel. Use the dropdown to search for security groups by name. Check the box next to each security group you want to include in the policy, and uncheck any groups you want to remove. The counter shows how many groups are currently selected. Click the **Update Security Groups** button to save the membership changes. A confirmation notification will appear. To discard your changes without saving, click **Cancel**. When you add a security group to a policy, all current members of that group immediately gain access to files protected by the policy. When you remove a security group, all users who were accessing the policy solely through that group will lose access. ## Managing Individual Users The **Users** tab displays all individual users currently assigned to the protection policy. Each row in the table shows: | Column | Description | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------- | | **Member** | The user's profile picture, display name, and email address. A **Gate Dropped** badge is shown if the user's gate has been dropped. | | **Email** | The user's email address. | | **Role** | The role assigned to this user within the policy (Administrator or Member). | | **Joined** | The date the user was added to the policy. | ### Adding or Removing Users On the protection policy's details page, click the **Users** tab. Click the **Edit Users** button above the table. The table view will be replaced with a user selection panel. Use the dropdown to search for users by name or email. Check the box next to each user you want to include in the policy, and uncheck any users you want to remove. Each user's profile picture, name, and email address are displayed to help you identify the right person. The counter shows how many users are currently selected. Click the **Update Users** button to save the membership changes. A confirmation notification will appear. To discard your changes without saving, click **Cancel**. ## Security Groups vs. Individual Users Both security groups and individual users can be added to a protection policy, and they can be used together. Choosing between them depends on how you want to manage access: | Approach | Best For | Advantages | | -------------------- | ------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Security groups** | Teams, departments, or roles that share the same access needs. | Membership is automatic — when users are added to or removed from the security group, their policy access updates accordingly. Easier to manage at scale. | | **Individual users** | One-off access grants, external collaborators, or users who don't fit neatly into a group. | Fine-grained control over exactly who has access. No need to create a dedicated security group for a single user. | | **Both** | Policies that need broad team access plus specific individual additions. | Combine the scalability of groups with the flexibility of individual assignments. | A user's access to a protection policy is the **union** of all their membership paths. If a user is both a member of an assigned security group and added as an individual user, they have access through both paths. Removing them from the security group does not revoke their individual membership, and vice versa. ## Understanding the Impact of Membership Changes When you add or remove members from a protection policy, the changes take effect immediately: ### Adding Members * **Security group added** — All current members of the security group can immediately access files protected by the policy. Future users added to the group will also gain access. * **Individual user added** — The user can immediately access files protected by the policy. ### Removing Members * **Security group removed** — Users who were accessing the policy solely through that security group will lose access immediately. Users who are also added as individual members or belong to another assigned security group will retain access. * **Individual user removed** — The user loses their individual access immediately. If they are also a member of an assigned security group, they retain access through that group. Removing a security group from a policy can affect many users at once. Before removing a group, consider how many users belong to it and whether any of them still need access to the policy's protected files. ## Common Membership Configurations Here are some common patterns for configuring protection policy membership: Assign a security group like **Engineering** or **Finance** to the policy. All current and future members of that department automatically get access. Add multiple security groups (e.g., **Engineering** and **Legal**) to the policy, and supplement with individual users from other teams who need access. Create a dedicated security group for executives, add it to the policy, and do not add any other groups or users. Only executives will have access. Add an individual user who needs short-term access. When their access period is over, remove them from the policy's Users tab. ## Relationship to Access Controls Membership determines **who** is authorized to access a policy's files, but [access controls](/help/command/protection-policies/access-controls) determine **how** they can access them. Even if a user is a member of a policy, they must still satisfy any access control conditions (such as location checks, device verification, or MFA verification) before they are granted access to the file. If a policy has no access controls configured, members are granted access without any additional conditions. ## Troubleshooting Verify the following: * The user is a member of the policy — either through a security group assignment on the **Security Groups** tab or as an individual user on the **Users** tab. * [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-protection-policies) is not active on the policy. * [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-users) is not active on the user. * The policy's [access controls](/help/command/protection-policies/access-controls) do not have conditions the user cannot satisfy (e.g., country restrictions, device OS requirements, MFA verification). * The tenant-level [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-tenant) is not active. Check whether those users are also assigned as individual members on the **Users** tab, or whether they belong to another security group that is still assigned to the policy. A user retains access as long as they have at least one active membership path. Ensure the security group you added is the correct one by verifying its members on the [Security Groups](/help/command/users/security-groups) page. Also check whether the policy has [access controls](/help/command/protection-policies/access-controls) that may be blocking access based on location, device, or authentication conditions. Ask the user to restart their desktop app or refresh their browser session. If no security groups and no individual users are assigned to a policy, it is open to all tenant users by default. Add at least one security group or individual user to the policy to restrict access. These buttons are only visible to users who have the **Protection Policies** permission. Check your [security group](/help/command/users/security-groups) membership to confirm you have this permission. If not, contact your tenant administrator. Roles are assigned when members are added and reflect the role configuration at that time. To change a member's effective role, you can remove and re-add them. Members default to the **Member** role. # Protection Policies Overview Source: https://theodosian.com/help/command/protection-policies/overview Learn how protection policies control access to your encrypted data. Protection policies are the central mechanism in Theodosian for controlling who can access your encrypted files and under what conditions. Every file encrypted by Theodosian is governed by one or more protection policies, which determine which users and security groups can decrypt and open the file, and what access control rules must be satisfied before access is granted. You must have the **Protection Policies** permission to create, edit, or delete protection policies. By default, users in the **Global Administrator** security group have this permission. ## What Is a Protection Policy? A protection policy is a named set of rules that governs access to encrypted files. Each policy defines: * **Who** can access the files — through security group and individual user membership. * **How** they can access the files — through access control rules that evaluate conditions like location, device, and authentication status before granting or denying access. When a user attempts to open an encrypted file on the desktop app, Theodosian evaluates the protection policy attached to that file. If the user is a member of the policy and satisfies all access control conditions, the file is decrypted and opened. If not, access is denied. ## Key Concepts ### Members Every protection policy has a membership list that determines who is authorized to access files under that policy. Members can be added in two ways: * **Security groups** — All users who belong to the assigned security group automatically become members of the policy. If new users are added to the security group later, they inherit access to the policy's files. * **Individual users** — Specific users can be added directly to the policy, independent of any security group. If no security groups or individual users are associated with a policy, **all users in the tenant** can access files under that policy. For details on adding and removing members, see [Managing Members](/help/command/protection-policies/managing-members). ### Roles Each member (security group or individual user) in a protection policy is assigned a role: | Role | Description | | ----------------- | ----------------------------------------------------------------------------- | | **Administrator** | Can manage the policy and has full access to files protected by it. | | **Member** | Can access files protected by the policy but cannot modify the policy itself. | By default, new members are assigned the **Member** role. ### Access Controls Access controls are optional rules that define additional conditions a user must satisfy before they can open an encrypted file — even if they are a member of the policy. Access controls are built using a visual workflow editor where you can chain together condition checks, verification steps, and actions. For example, you can require that a user must be located in the United States, using a specific operating system, and have verified their identity via MFA before a file is decrypted. For details on building access control workflows, see [Access Controls](/help/command/protection-policies/access-controls). For pre-built access control configurations, see [Access Control Templates](/help/command/protection-policies/access-control-templates). ### Protected Files Files become protected by a policy when they are encrypted under that policy — either manually through the [desktop app](/help/desktop/daily-use/encrypting-files) or automatically through [data connectors](/help/command/data-connectors/encryption-automations). The protection policy list shows how many files are currently protected by each policy. ### Drop the Gate Each protection policy has its own [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-protection-policies) control. When the gate is dropped on a policy, all data encrypted under that policy becomes immediately inaccessible — no user can decrypt any file governed by that policy, regardless of their membership or access controls. New data can still be added to the policy, but existing encrypted data cannot be accessed until the gate is removed. ## How Protection Policies Fit Together Protection policies work alongside other Theodosian features to provide layered security: Security groups organize users and grant administrative permissions. They can also be assigned as members of protection policies, giving all group members access to the policy's files. Access controls add conditional logic on top of policy membership. Even if a user is a member of a policy, access controls can require additional verification before granting access. Data connectors automate encryption by scanning cloud storage providers and encrypting files under specific protection policies based on rules you define. The desktop app enforces protection policies in real time. When a user opens an encrypted file, the app evaluates the policy and access controls before decrypting. ## Viewing Protection Policies In the sidebar, click **Protection Policies** to open the Protection Policies list page. The protection policies table displays the following columns: | Column | Description | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Name** | The name of the protection policy. If [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-protection-policies) is active on the policy, a **Gate Dropped** badge is shown next to the name. | | **Security Groups** | The number of security groups assigned to the policy. | | **Users** | The number of individual users assigned to the policy. | | **Protected Files** | The number of files currently encrypted under this policy. | Click any row to open the policy's details page. ### Searching Policies Type a policy name into the **Search policy...** field at the top of the table. Results update as you type. ### Tenant Gate Status If [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-tenant) has been enabled at the tenant level, an information banner is displayed at the top of the protection policies list: > **Drop the Gate has been enabled at tenant level. No data is able to be accessed.** This tenant-level gate overrides all individual policy settings — no encrypted data in any policy can be accessed until the tenant gate is removed. ## Protection Policy Details Clicking on a protection policy in the list opens its details page. The details page is organized into four tabs: | Tab | Description | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Security Groups** | View and manage the security groups assigned to this policy. See [Managing Members](/help/command/protection-policies/managing-members). | | **Users** | View and manage the individual users assigned to this policy. See [Managing Members](/help/command/protection-policies/managing-members). | | **Access Controls** | Open the visual access control editor to define conditions for file access. See [Access Controls](/help/command/protection-policies/access-controls). | | **Drop the Gate** | Enable or disable the emergency access lock on this specific policy. See [Drop the Gate on Protection Policies](/help/command/anomalous-activity/drop-the-gate-on-protection-policies). | From the details page header, you can also: * **Edit Policy** — Rename the protection policy. * **Delete Policy** — Permanently delete the policy and remove all access controls on its protected files. ## Editing a Policy Name Click on a protection policy in the list to open its details page. Click the **Edit Policy** button in the top-right corner of the page. In the dialog that appears, enter the new name for the protection policy. Click **Save** to apply the change. The page header will update to reflect the new name. ## Deleting a Policy Click on a protection policy in the list to open its details page. Click the **Delete Policy** button (red) in the top-right corner of the page. A confirmation dialog will appear warning that all controls on protected files regarding this policy will be removed. Click **Remove** to permanently delete the protection policy. Deleting a protection policy removes all access controls associated with it. Files that were encrypted under this policy will have their policy association removed. This action cannot be undone. ## Getting Started Create your first protection policy to start controlling access to encrypted data. Add security groups and users to your policies to define who can access protected files. Build conditional access workflows to enforce location, device, and authentication requirements. Get started quickly with pre-built access control templates for common compliance scenarios. ## Troubleshooting The Protection Policies section is only visible to users who have the **Protection Policies** permission through their [security group](/help/command/users/security-groups) membership. Contact your tenant administrator to request access. This means a Global Administrator has activated [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-tenant) on the entire tenant. No encrypted data can be accessed until the tenant-level gate is removed. Contact your Global Administrator to resolve this. Check the protection policy's membership. If no security groups or individual users are assigned to the policy, **all users in the tenant** have access by default. Add specific security groups or users to restrict access. Also review the policy's [access controls](/help/command/protection-policies/access-controls) to ensure the appropriate conditions are configured. Verify that the user is a member of the protection policy — either through a security group assignment or as an individual user. Also check whether [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-protection-policies) is active on the policy or on the [user](/help/command/anomalous-activity/drop-the-gate-on-users), and review the policy's access controls for conditions that the user may not satisfy (e.g., country restrictions, OS requirements). Policy deletion is permanent and cannot be undone. You will need to create a new protection policy, reconfigure its members and access controls, and re-encrypt the affected files under the new policy. # Creating a Tenant Source: https://theodosian.com/help/command/tenant/creating-a-tenant Set up a new tenant organization in Theodosian Command to start protecting your data. A tenant is the top-level organizational unit in Theodosian. It contains all of your users, protection policies, encryption keys, data connectors, and compliance records. Every user and file in Theodosian belongs to a tenant. When you sign up for Theodosian for the first time, you will be guided through a two-step process to create your tenant and set up billing. The user who creates the tenant automatically becomes its **Global Administrator** with full permissions across the platform. ## Before You Begin To create a tenant, you need: * A valid email address that is not already associated with an existing Theodosian tenant. * A payment method for the billing setup step (credit card or other supported payment method). ## Step 1: Create Your Tenant Navigate to [Theodosian Command](https://dash.theodosian.com/signup) and enter your email address on the sign-up page. Click **Sign Up** to begin. Check your email inbox for a message from Theodosian containing a magic link. Click the link to verify your identity. The magic link will open Theodosian Command in your browser and automatically redirect you to the tenant creation form. You will see the **Create a tenant** form with a progress bar indicating you are on step 1 of 2. Fill in the following fields: | Field | Description | | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Tenant Name** | The name of your organization. This is how your tenant will be identified across Theodosian. You can change this later in [Tenant Settings](/help/command/tenant/tenant-settings). | | **User Name** | Your display name as the first user and administrator of the tenant. This is pre-populated from your email address but can be changed. | | **Email** | Your email address. This is pre-filled from sign-up and cannot be changed. | | **Jurisdiction** | The data residency jurisdiction for your tenant. See the section below for details. | | **Terms of Service** | A required checkbox at the bottom of the form. You must accept the [Terms of Service](https://theodosian.com/legal/terms-of-service) before you can create your tenant. | | **End User License Agreement (EULA)** | A required checkbox confirming acceptance of the End User License Agreement before tenant creation can continue. | | **Services Privacy Policy** | A required checkbox confirming acceptance of the Services Privacy Policy before tenant creation can continue. | Choose where your tenant data will be stored and processed. The following jurisdictions are available: | Jurisdiction | Description | | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Global** | Data is stored and processed in the default global region. Suitable for most organizations without specific regional compliance requirements. | | **EU** | Data is stored and processed within the European Union. Recommended for organizations subject to GDPR or other EU data residency requirements. | | **US FedRAMP** | Data is stored and processed in FedRAMP-authorized infrastructure within the United States. Designed for organizations that require US federal compliance standards. | The jurisdiction you select **cannot be changed** after your tenant is created. Choose carefully based on your organization's compliance and data residency requirements. For more information, see [Tenant Data Residency](/help/command/tenant/tenant-data-residency). At the bottom of the form, review and accept the required legal agreements: * [**Terms of Service (TOS)**](/help/command/legal/terms-of-service) * [**End User License Agreement (EULA)**](/help/command/legal/user-agreements) * [**Services Privacy Policy**](/help/command/legal/user-agreements) The **Create Tenant** button remains disabled until all required legal checkboxes are checked. Click **Create Tenant** to provision your new tenant. Theodosian will set up your organization and automatically sign you in as the Global Administrator. Your initial acceptance of the Terms of Service, End User License Agreement, and Services Privacy Policy is recorded as part of tenant creation. You will then be redirected to the billing setup step. ## Step 2: Set Up Billing After your tenant is created, you will be redirected to the billing setup page. Theodosian will present the available subscription plan for your organization. If a **free trial** is available, the trial duration will be displayed alongside the plan details so you know exactly how long you can evaluate the platform before charges begin. You will be directed to a secure Stripe checkout page to enter your payment details. Fill in your billing information and confirm the subscription. All payment processing is handled securely by [Stripe](https://stripe.com). Theodosian does not store your credit card information. Once payment is confirmed, you will be redirected to the **Billing** page inside your new tenant. Your tenant is now fully set up and ready to use. ## What Happens Next After your tenant is created and billing is configured, you can begin setting up your organization: Add team members to your tenant and assign them roles. Define policies that control how your files are encrypted and who can access them. Set session durations, enforce MFA, and configure decrypt-to-disk settings. Link cloud storage providers to automate encryption across your organization. ## Troubleshooting Check your spam or junk folder. If the email still hasn't arrived after a minute, return to the sign-up page and try again. Make sure you are entering a valid email address. Magic links are valid for a limited time. If your link has expired, go back to the sign-up page and request a new one by entering your email address again. If you receive an error during tenant creation, check the following: * **All required fields are filled in** — Tenant Name and User Name are required. * **All required legal checkboxes are selected** — You must accept the Terms of Service, End User License Agreement, and Services Privacy Policy before creating the tenant. * **Your verification token is still valid** — If too much time has passed since you clicked the magic link, you may need to sign up again to get a new token. * **Your email is not already registered** — If your email is already associated with an existing tenant, you cannot create a new one from the sign-up flow. Sign in to your existing tenant instead, or use a different email address. If your organization does not have specific data residency or regulatory requirements, select **Global**. If you are subject to EU data protection regulations such as GDPR, select **EU**. If you need to meet US federal compliance standards, select **US FedRAMP**. Contact [support](https://theodosian.com/support) if you need guidance. If the Stripe checkout did not complete successfully, you will be redirected back to the billing setup page to try again. If you continue to experience issues, visit [Billing Management](/help/command/billing/billing-management) or contact [support](https://theodosian.com/support). # Managed Updates Source: https://theodosian.com/help/command/tenant/managed-updates Control how and when desktop app updates are rolled out across your tenant. Managed Updates gives Global Administrators control over when new versions of the Theodosian Desktop App are deployed to devices in their tenant. When enabled, devices will not automatically update to the latest version — instead, an administrator must explicitly approve each new version before it is rolled out. This is useful for organizations that need to test new releases internally, coordinate rollouts with change management processes, or maintain a consistent version across all devices. When Managed Updates is **disabled** (the default), all devices in the tenant automatically receive updates as soon as a new version is released. ## Requirements * You must be a **Global Administrator** to enable, disable, or approve managed updates. * Navigate to **Settings** → **Managed Updates** in the sidebar to access this page. ## Enabling Managed Updates In the sidebar, click **Settings**, then select **Managed Updates** under the **Tenant** section. Toggle the **Managed Client Updates** switch to the **on** position. Once enabled, automatic updates are paused for all devices in the tenant. Devices will remain on their current version until you approve a newer one. ## Approving a New Version When a new version of the Theodosian Desktop App is available, the Managed Updates page will display the version details and an approval button. When a new version is available, the page will display both the **latest approved version** and the **latest available version** if they differ. Click the **Approve version X.X.X** button to approve the new version. Once approved, all devices in the tenant will begin receiving the update. A confirmation message will appear when the version is approved successfully. If the latest approved version already matches the latest available version, no action is needed — all devices are already on the most recent approved release. ## Disabling Managed Updates If you no longer need to control update rollouts, you can disable Managed Updates to return to automatic updates. On the **Managed Updates** page, toggle the **Managed Client Updates** switch to the **off** position. A confirmation dialog will appear asking you to confirm. Click **Confirm** to proceed. Disabling Managed Updates will cause all devices in the tenant to automatically update to the latest available version. Make sure your organization is ready for this before confirming. ## How It Works | State | Behavior | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Managed Updates off** | All devices automatically update to the latest version as soon as it is released. | | **Managed Updates on, version approved** | Devices update to the approved version. Newer versions are held until explicitly approved. | | **Managed Updates on, new version available** | Devices remain on the current approved version. The new version is displayed on the Managed Updates page, waiting for approval. | ## Troubleshooting The Managed Updates toggle is only visible to users who are members of the **Global Administrator** security group. If you do not see the toggle, contact your tenant administrator to request access. After approving a version, devices will check for updates on their next update cycle. This may take a short time depending on the device's check-in interval. Users can also manually check for updates from the desktop app. Managed Updates only allows you to approve the latest available version. Rolling back to a previous version is not supported through this page. If you need assistance with a rollback, contact [support](https://theodosian.com/support). # Switching Tenants Source: https://theodosian.com/help/command/tenant/switching-tenants Switch between tenants, add new tenants, and manage multiple workspaces from the Theodosian Command sidebar. If your account is associated with more than one tenant, you can switch between them directly from the Theodosian Command sidebar without signing out. Each tenant you sign into is stored as a workspace, and you can move between them at any time. ## Switching to Another Tenant In the top-left corner of the sidebar, click the **tenant name** to open the tenant dropdown menu. The dropdown displays all tenants associated with your current user account. Click the tenant you want to switch to. If you have an active session for that tenant, Theodosian Command will switch to it immediately and load its dashboard. The currently selected tenant is indicated with a **checkmark** next to its name. If you are not currently signed in to the tenant you selected, you will be redirected to the sign-in flow. Enter your email address, verify via the magic link, and complete any MFA verification if required. Once signed in, you will be taken to that tenant's dashboard. Tenants that require sign-in display a **Not logged in** label next to their name in the dropdown. Depending on the tenant and your account status, you may be prompted to accept one or more legal agreements before accessing the tenant. Global Administrators may need to accept updated [Terms of Service](/help/command/legal/terms-of-service), and users may also be asked to accept the [End User License Agreement and Services Privacy Policy](/help/command/legal/user-agreements). ## Adding a New Tenant You can add another tenant to your workspace list without leaving Theodosian Command. Click the **tenant name** in the top-left corner of the sidebar to open the tenant dropdown menu. At the bottom of the dropdown, click **Add Tenant**. You will be redirected to the sign-in page. Enter the email address associated with the tenant you want to add and complete the sign-in flow. Once verified, the new tenant will appear in your tenant dropdown alongside your existing workspaces. Adding a tenant from the dropdown signs you into an existing tenant that your email is already a member of. To create a brand new tenant, see [Creating a Tenant](/help/command/tenant/creating-a-tenant). ## Signing Out You have two sign-out options available from the sidebar: | Option | Where to find it | What it does | | ----------------------------- | ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- | | **Sign Out** (current tenant) | Click your **user name** at the bottom of the sidebar, then select **Sign Out**. | Signs you out of the currently selected tenant only. Your other tenant sessions remain active. | | **Sign Out All Tenants** | Click the **tenant name** at the top of the sidebar, then select **Sign Out All Tenants**. | Signs you out of every tenant in your workspace list and returns you to the sign-in page. | ## How Workspaces Work Each time you sign into a tenant, Theodosian Command stores it as a **workspace** in your browser. This means: * **Sessions persist between visits** — You do not need to sign in again each time you open Theodosian Command, unless your session has expired or you have explicitly signed out. * **Multiple tenants, one browser** — You can maintain active sessions across several tenants and switch between them instantly. * **Sessions are independent** — Signing out of one tenant does not affect your sessions in other tenants. Workspaces are stored in your browser's local storage. If you clear your browser data or switch to a different browser, you will need to sign in to your tenants again. ## Troubleshooting The tenant dropdown only shows tenants associated with the same user account you are currently signed in with. If the tenant is linked to a different email address, click **Add Tenant** and sign in with the correct email. Also note that expired demo tenants are automatically hidden from the dropdown. Your session for that tenant may have expired. Session duration is configured per tenant by its administrator — see [Tenant Security](/help/command/tenant/tenant-security) for details. Click the tenant in the dropdown to start a new sign-in flow. Navigate to [Theodosian Command](https://dash.theodosian.com/signin) and sign in with your email address. If your email is associated with multiple tenants, you will be prompted to select one. Once signed in, you can add your other tenants back using the **Add Tenant** option in the sidebar dropdown. # Tenant Data Residency Source: https://theodosian.com/help/command/tenant/tenant-data-residency Understand how Theodosian handles data residency and where your tenant data is stored. Data residency determines the geographic region where your tenant's data is stored and processed. Theodosian allows you to choose a jurisdiction when you [create your tenant](/help/command/tenant/creating-a-tenant), ensuring your organization meets its regulatory and compliance obligations. ## Available Jurisdictions Theodosian supports the following data residency jurisdictions: | Jurisdiction | API Identifier | Description | | -------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Global** | `null` | Data is stored and processed in the default global region. This is the standard option for organizations without specific regional data residency requirements. | | **EU** | `eu` | Data is stored and processed entirely within the European Union. Designed for organizations subject to GDPR or other EU data protection regulations. | | **US FedRAMP** | `fedramp` | Data is stored and processed in FedRAMP-authorized infrastructure within the United States. Intended for organizations that must comply with US federal security standards. | The available jurisdictions may vary depending on your deployment environment. Contact [support](https://theodosian.com/support) if you need a jurisdiction that is not listed. ## How Data Residency Works When you select a jurisdiction during tenant creation, Theodosian configures your tenant so that all data — including encryption keys, user records, compliance logs, and file metadata — is stored and processed within the chosen region. This applies to: * **Encryption keys** — All cryptographic keys generated for your tenant are created and stored within the selected jurisdiction. * **User and tenant data** — User profiles, security group memberships, and tenant configuration are stored in the jurisdiction's data center. * **Compliance and audit logs** — All audit events and compliance records remain within the jurisdiction. * **API routing** — API requests for your tenant are automatically routed to the correct regional endpoint based on your jurisdiction. ## Viewing Your Jurisdiction You can view your tenant's current data residency jurisdiction in two places: 1. **Breadcrumb bar** — A jurisdiction badge is displayed in the breadcrumb navigation at the top of every page in Theodosian Command (e.g. "Global", "EU", or "US FedRAMP"). 2. **Tenant Settings** — Navigate to **Settings** > **General** to see the **Tenant Data Residency** field, which displays the region where your data is stored and processed. Click **Settings** in the bottom of the sidebar to open the settings panel. Under the **Tenant** section in the settings sidebar, click **General**. The **Tenant Data Residency** row displays your current jurisdiction, for example: *"Tenant data is stored and processed in the EU region."* ## Jurisdiction Is Permanent Your tenant's data residency jurisdiction **cannot be changed** after the tenant is created. This is by design — moving data between jurisdictions would compromise the compliance guarantees that data residency provides. If your organization's requirements change and you need a different jurisdiction, you will need to create a new tenant in the desired jurisdiction and migrate your users and policies manually. Contact [support](https://theodosian.com/support) for assistance with this process. ## Choosing the Right Jurisdiction Select **Global** if your organization does not have specific regulatory requirements around where data is stored. This is the default option and is suitable for most organizations. Select **EU** if your organization is subject to the General Data Protection Regulation (GDPR) or other European data protection laws that require personal data to remain within the European Union. This is also recommended if the majority of your users and operations are based in Europe. Select **US FedRAMP** if your organization needs to comply with the Federal Risk and Authorization Management Program (FedRAMP) or other US federal security standards. This jurisdiction uses FedRAMP-authorized infrastructure and is designed for government agencies and their contractors. # Tenant Security Source: https://theodosian.com/help/command/tenant/tenant-security Configure session duration, MFA enforcement, decrypt-to-disk settings, and emergency access controls for your tenant. The Tenant Security page lets Global Administrators control security policies that apply to every user and device in the tenant. You can access these settings by navigating to **Settings → Tenant → Security** in the sidebar. Only users in the **Global Administrator** security group can view and modify tenant security settings. Other users will not see these configuration options. ## Accessing Tenant Security Settings Click **Settings** in the bottom of the sidebar navigation. In the Settings sidebar under the **Tenant** heading, click **Security**. The Tenant Security page will load with your current configuration. ## Session Duration Session duration controls how long a user's session remains valid before they are required to sign in again. This applies to all users across the tenant, including sessions on both the web panel and the desktop app. On the Tenant Security page, find the **Session Duration** setting. The current duration in days is displayed. Click the **Update Duration** button. In the dialog that appears, enter the new session duration in days. The minimum value is 1 day. Click **Save Changes** to apply the new session duration. All future sessions will use the updated duration. Existing sessions will continue using their original expiration time. The default session duration is **30 days**. Shorter durations improve security by requiring users to re-authenticate more frequently. Longer durations improve convenience for users who work in low-risk environments. ## Enforce Multi-Factor Authentication (MFA) When MFA enforcement is enabled, every user in the tenant is required to set up multi-factor authentication. Users who have not yet configured MFA will be prompted to do so the next time they sign in. ### Enabling MFA Enforcement Toggle the **Enforce Multi-Factor Authentication (MFA)** switch to the on position. MFA enforcement takes effect immediately. Users without MFA configured will be required to set it up on their next login. ### Disabling MFA Enforcement When you toggle MFA enforcement off, a confirmation dialog will appear asking you to confirm the change. Click **Disable MFA Enforcement** to proceed. Once disabled, MFA becomes optional — users who have already configured MFA will continue to use it, but users without MFA will no longer be required to set it up. Disabling MFA enforcement reduces the security of your tenant. Any user without MFA configured will be able to sign in with only email verification. Consider your organization's security requirements carefully before disabling this setting. For more information about how individual users set up MFA, see [Multi-Factor Authentication](/help/command/account/multi-factor-authentication). ## Allow Decrypt to Disk The **Allow Decrypt to Disk** setting controls whether desktop app users can temporarily decrypt protected files to disk. When allowed, the desktop app can write decrypted file data to the local filesystem when necessary to open files with third-party applications. * **Enabled** — Desktop devices are permitted to temporarily decrypt data to disk if necessary to open files. * **Disabled** — Desktop devices are not permitted to decrypt data to disk. Files can only be accessed through in-memory decryption. Toggle the **Allow Decrypt to Disk** switch to change this setting. The change takes effect immediately across all devices in the tenant. Disabling decrypt to disk provides stronger data protection by ensuring that unencrypted file contents never touch the local filesystem. However, this may limit compatibility with some third-party applications that require direct file access. ## Drop the Gate on Tenant **Drop the Gate** is an emergency security control that immediately blocks all access to encrypted data across the entire tenant. When activated, no user or device in the tenant will be able to decrypt or access any files encrypted under this tenant. New data can still be encrypted and added to protection policies, but existing encrypted data becomes inaccessible. This is designed for situations where you suspect a tenant-wide security breach and need to immediately revoke all data access. ### Enabling Drop the Gate On the Tenant Security page, find the **Drop the Gate on Tenant** setting and toggle the switch to the on position. A confirmation dialog will appear warning you that this will prevent all data encrypted with this tenant from being accessed. Click **Proceed** to activate Drop the Gate. ### Removing Drop the Gate To restore normal access, toggle the **Drop the Gate on Tenant** switch back to the off position. Access to encrypted data will be restored immediately for all users and devices. Dropping the Gate is an aggressive security measure that affects every user in your tenant. Use this only in genuine emergency situations. For more granular controls, consider [dropping the gate on individual users](/help/command/anomalous-activity/drop-the-gate-on-users) or [specific protection policies](/help/command/anomalous-activity/drop-the-gate-on-protection-policies) instead. ## Settings Summary | Setting | Description | Default | | --------------------------- | ------------------------------------------------------------------------------------ | -------- | | **Session Duration** | How long user sessions remain valid before requiring re-authentication. | 30 days | | **Enforce MFA** | Requires all users to configure multi-factor authentication. | Disabled | | **Allow Decrypt to Disk** | Permits desktop devices to temporarily write decrypted data to the local filesystem. | Disabled | | **Drop the Gate on Tenant** | Emergency control that blocks all access to encrypted data tenant-wide. | Disabled | ## Troubleshooting Tenant security settings are only visible to users in the **Global Administrator** security group. Contact your tenant administrator to request access, or check your security group membership under **Settings → Account → Security**. MFA enforcement takes effect on each user's next sign-in. Users with active sessions will not be prompted until their current session expires or they sign out and sign back in. You can remove Drop the Gate immediately by toggling the switch back to the off position on the Tenant Security page. Access to all encrypted data will be restored as soon as the gate is removed. Session duration changes apply to new sessions only. Your current session will continue using its original expiration time. To use the new duration, sign out and sign back in. # Tenant Settings Source: https://theodosian.com/help/command/tenant/tenant-settings Update your tenant name, profile picture, and view your data residency region. The Tenant Settings page lets Global Administrators manage the general identity of their tenant — including the display name, profile picture, and data residency information. These settings are visible across Theodosian Command and help identify your organization to team members. Only users in the **Global Administrator** security group can update tenant settings. Other users can view the settings but cannot make changes. ## Accessing Tenant Settings Click **Settings** in the bottom of the sidebar. The sidebar will switch to the settings navigation. Under the **Tenant** heading in the settings sidebar, click **General**. The Tenant Settings page will load. ## Tenant Name The tenant name is how your organization is identified throughout Theodosian Command — in the sidebar, breadcrumbs, workspace cards, and anywhere your tenant is referenced. ### Updating the Tenant Name On the Tenant Settings page, find the **Tenant Name** row and click the **Update Name** button on the right. A dialog will appear with the current tenant name pre-filled. Edit the **Tenant Name** field to your desired name. Click **Save Changes** to apply the new name. A confirmation message will appear once the update is successful. The new name will be reflected across the platform immediately. ## Tenant Profile Picture The tenant profile picture appears in the sidebar, workspace cards, and other areas where your tenant is displayed. It helps visually distinguish your tenant, especially if you or your team members belong to multiple tenants. ### Uploading a Profile Picture On the Tenant Settings page, find the **Tenant Profile Picture** row. Hover over the avatar on the right — a cloud upload icon will appear. Click on it to open the file picker. Choose an image file from your computer. The image must meet the following requirements: | Requirement | Details | | ---------------- | --------------------------------------------- | | **File type** | Any image format (PNG, JPEG, WebP, GIF, etc.) | | **Maximum size** | 1 MB | The profile picture uploads automatically after you select a file. A confirmation message will appear once the upload is complete. ### Removing a Profile Picture If your tenant already has a profile picture, a **Clear Avatar** link will appear below the image. Click it to remove the profile picture and revert to the default tenant avatar. The removal is applied automatically. ## Tenant Data Residency The **Tenant Data Residency** row displays the jurisdiction region where your tenant's data is stored and processed. This is set during [tenant creation](/help/command/tenant/creating-a-tenant) and is shown here for reference. | Jurisdiction | Display Label | | ---------------- | ------------- | | Global (default) | Global | | European Union | EU | | US Federal | US FedRAMP | The data residency jurisdiction **cannot be changed** after your tenant is created. If you need to change your data residency region, you will need to create a new tenant. For more information, see [Tenant Data Residency](/help/command/tenant/tenant-data-residency). ## Permissions | Action | Required Role | | -------------------------------- | ---------------------- | | View tenant settings | Any authenticated user | | Update tenant name | Global Administrator | | Upload or remove profile picture | Global Administrator | If you are not a Global Administrator, the **Update Name** button will be replaced with a message reading "Global admin access required", and the profile picture area will not be interactive. ## Troubleshooting The ability to update the tenant name is restricted to users in the **Global Administrator** security group. If you need to make changes, ask a Global Administrator in your organization to update the name or to add you to the Global Administrator group. Ensure your image file is under 1 MB and is a valid image format. If the file is too large, resize or compress it before uploading. If the issue persists, try a different image file or contact [support](https://theodosian.com/support). Data residency is permanently set at tenant creation and cannot be modified. If your compliance requirements have changed, you will need to create a new tenant with the correct jurisdiction and migrate your users and policies. Contact [support](https://theodosian.com/support) for assistance. # Manage User Devices Source: https://theodosian.com/help/command/users/manage-user-devices View and manage the devices associated with users across your tenant. Every time a user signs into Theodosian — whether through the web panel or the desktop app — a device session is created and tracked. The **Manage Devices** tab on a user's profile gives administrators visibility into all active sessions and the ability to remotely sign users out of specific devices. You must have the **User Management** permission to view and manage another user's devices. By default, users in the **Global Administrator** security group have this permission. To manage your own device sessions, see [Device Sessions](/help/command/account/device-sessions). ## Accessing a User's Devices In the sidebar, click **Users** to open the User Management page. Click on the row for the user whose devices you want to manage. This opens their profile page. Click the **Manage Devices** tab to view all active device sessions for that user. ## Understanding Device Sessions Each device session is displayed as a card showing the following information: | Field | Description | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | **Session type** | Either **Desktop Agent** (for the Theodosian desktop app) or **Web Session** (for Theodosian Command in the browser). | | **Operating system** | The OS of the device, such as macOS, Windows, or Linux. An OS-specific icon is displayed alongside the session card. | | **Last seen** | A relative timestamp showing when the device was last active (e.g., "5 minutes ago", "2 days ago"). | | **Location** | The city and country where the device was last seen, based on IP geolocation. This is only displayed if location data is available. | | **Current Device** | If you are viewing from the same device, a **Current Device** label is shown in green. | ## Signing Out a User's Device If you suspect unauthorized access or need to force a user to re-authenticate on a specific device, you can remotely sign them out. On the **Manage Devices** tab, locate the device session card you want to terminate. Click the **Sign Out** button on the right side of the device session card. A confirmation dialog will appear asking if you are sure you want to sign out the user from this device session. Click **Sign Out** to proceed. The user will be immediately signed out of that specific device. The session card will be removed from the list. The user will need to sign in again on that device to continue using Theodosian. Signing out a single device only terminates that specific session. The user's other active sessions on other devices are not affected. To sign a user out of **all** devices at once, use the **Close all sessions** action from the user's profile [actions menu](/help/command/users/manage-users#admin-actions-menu). ## When No Devices Are Found If a user has no active device sessions — for example, if they have never signed in or all of their sessions have expired — the Manage Devices tab will display an empty state message: > **No devices found** — There are no active sessions on any devices. This is normal for users whose status is **User Never Logged In**, or for users whose sessions have all expired or been manually closed. ## Desktop Agent vs. Web Sessions Theodosian tracks two types of device sessions: | Session Type | Description | | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Desktop Agent** | A session created when the user signs into the Theodosian desktop app on Windows, macOS, or Linux. Desktop sessions are used for file encryption and decryption on the local machine. | | **Web Session** | A session created when the user signs into Theodosian Command through a web browser. Web sessions are used for administration, policy management, compliance review, and other web panel features. | Both session types are subject to the tenant's [session duration](/help/command/tenant/tenant-security) setting. When a session expires, it is automatically removed and the user must sign in again. ## Common Scenarios Navigate to the user's profile, open the **Manage Devices** tab, and sign out the session associated with the lost device. If you are unsure which session corresponds to the lost device, you can use the operating system, last seen time, and location to identify it. For maximum safety, consider using **Close all sessions** from the [actions menu](/help/command/users/manage-users#admin-actions-menu) to revoke every active session, or [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-users) on the user to immediately block all access to encrypted data. If you see a device session originating from an unexpected city or country, this may indicate unauthorized access. Sign out that specific device session immediately. Consider also resetting the user's [MFA](/help/command/users/manage-users#resetting-a-users-mfa) and closing all of their sessions. Review the [audit log](/help/command/compliance/audit-log) for any suspicious activity from that session. [Remove the user](/help/command/users/manage-users#removing-a-user) from the tenant. This will revoke all of their sessions and remove all associations. If you need to block access immediately before completing the removal process, use [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-users) on the user first. Users may accumulate multiple sessions if they sign in from different browsers or devices without signing out. You can selectively sign out older or unused sessions from the **Manage Devices** tab, or use **Close all sessions** to clear everything and have the user sign in fresh. ## Troubleshooting The **Manage Devices** tab is available on the user profile page. Make sure you have navigated to a specific user by clicking their row in the user list. If you still don't see the tab, verify that you have the **User Management** permission through your [security group](/help/command/users/security-groups) membership. The **Sign Out** button is only shown if you have the **User Management** permission. If you are viewing your own devices, the button is always available. If you are viewing another user's devices and the button is missing, check your security group permissions. Signing out a device terminates that specific session. If the user has other active sessions on other devices, they will still be able to access Theodosian through those sessions. To revoke all access, use **Close all sessions** or [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-users). Location information is derived from IP geolocation and may not always be available. If the user is behind a VPN, corporate proxy, or a network that masks their IP address, location data may be missing or inaccurate. # Manage Users Source: https://theodosian.com/help/command/users/manage-users Edit user profiles, close sessions, reset MFA, manage devices, and remove users from your tenant. The User Management page is your central hub for administering the users in your Theodosian tenant. From here you can view all provisioned users, edit their details, manage their sessions and devices, reset their multi-factor authentication, and remove them from the tenant when necessary. You must have the **User Management** permission to manage other users. By default, users in the **Global Administrator** security group have this permission. You can always manage your own profile from the [Account Settings](/help/command/account/profile-management) page. ## Accessing User Management In the sidebar, click **Users** to open the User Management page. The user list displays all provisioned users in your tenant. Each row shows the following information: | Column | Description | | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Member** | The user's profile picture, display name, and email address. If the user has had their gate dropped, a **Gate Dropped** badge is shown next to their name. | | **Status** | Whether the user is **Active** (has signed in at least once) or **User Never Logged In** (has not yet accepted the invitation). | | **Notes** | The date the user joined the tenant, based on their earliest security group membership. | | **Actions** | Quick-action buttons for editing, closing sessions, and removing the user. | ## Searching and Filtering Users The user list supports both search and filtering to help you find specific users quickly. ### Search Type a name or email address into the **Search users...** field at the top of the table. Results update automatically as you type. The search is debounced to avoid excessive API calls. ### Filter by Security Group You can filter the user list to show only members of a specific security group: Click the **Filters** button next to the search bar. Choose **Security Group** from the available filter options. Search for and select one or more security groups. The user list will update to show only users who belong to the selected group(s). To clear the filter, click the **×** button on the filter chip that appears below the search bar. ## Viewing a User Profile Click any row in the user list to open that user's profile page. The profile page provides a detailed view of the user and is organized into several sections. ### User Header The top of the profile page displays a summary card with: * **Profile picture** — The user's avatar. Administrators can update another user's profile picture by clicking on it. * **Display name** and **email address**. * **Status badge** — Shows **Active** or **User Never Logged In**. * **Gate Dropped badge** — Displayed if [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-users) is active on the user. * **Joined date** — When the user first joined the tenant. * **MFA status** — Shows whether multi-factor authentication is currently enabled or disabled for the user. ### Admin Actions Menu When viewing another user's profile (not your own), a **⋮** menu button appears in the top-right corner of the header card. This menu provides the following actions: | Action | Description | | ---------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Reset MFA** | Removes the user's MFA configuration and revokes all their sessions. Only available if the user has MFA enabled. | | **Close all sessions** | Immediately signs the user out of all active sessions across web and desktop. | | **Remove user** | Permanently removes the user from the tenant and all associations. | ### Profile Tabs The profile page contains tabs for managing different aspects of the user: | Tab | Description | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Manage Profile** | Edit the user's name, email address, and nationality. | | **Manage Devices** | View and manage the user's active device sessions. See [Manage User Devices](/help/command/users/manage-user-devices) for details. | | **Drop the Gate** | Enable or disable the emergency access lock on this specific user. See [Drop the Gate on Users](/help/command/anomalous-activity/drop-the-gate-on-users). | When viewing your own profile from the user list, the **Manage Profile** tab displays a link to your [Account Settings](/help/command/account/profile-management) page instead of inline editing. The **Drop the Gate** tab is not shown for your own profile. ## Editing a User You can edit a user's name and email from either the user list or their profile page. ### Quick Edit from the User List Locate the user in the user list by browsing or using the search bar. In the **Actions** column, click the **pencil icon** button for that user. In the **Edit User** dialog, update the following fields: | Field | Description | | --------------- | ----------------------------------------------------------------------------------------------------------------- | | **Email** | The user's email address. Changing this updates their login identity. | | **User name** | The user's display name across Theodosian. | | **Nationality** | The user's nationality. Select from the searchable dropdown, or clear the selection to set it to "Not specified". | Email and User name are required. Nationality is optional. Click **Update User** to save the changes. A confirmation notification will appear. ### Edit from the User Profile Page Click on the user's row in the user list to navigate to their profile page. Ensure the **Manage Profile** tab is selected (it is the default tab). Edit the **Full name**, **Email address**, and **Nationality** fields as needed. You can also update the user's **profile picture** by clicking on their avatar in the header card. Click **Save Changes** at the bottom of the form. Changing a user's email address updates their login identity. The user will need to use the new email address the next time they sign in. Make sure the new address is correct before saving. ## Closing User Sessions Closing sessions immediately signs a user out of all active sessions across both the Theodosian Command web panel and the desktop app. This is useful if a user's account may be compromised or if you need to force a re-authentication. ### From the User List Locate the user in the user list. In the **Actions** column, click the **monitor with X icon** button. A confirmation dialog will appear asking if you want to close the user's sessions. Click **Close Sessions** to proceed. ### From the User Profile Click on the user's row in the user list. Click the **⋮** menu button in the top-right corner of the user header card. Click **Close all sessions** and confirm the action in the dialog that appears. The user will be signed out of all web and desktop sessions immediately. They will need to sign in again to continue using Theodosian. ## Resetting a User's MFA If a user loses access to their authenticator app or needs to reconfigure multi-factor authentication, you can reset their MFA from their profile page. Navigate to the user's profile by clicking their row in the user list. Click the **⋮** menu button in the top-right corner of the header card. Click **Reset MFA**. This option is only available if the user currently has MFA enabled. A warning dialog will appear explaining the consequences: * The user's current MFA configuration will be **removed**. * All active sessions for the user will be **revoked**. Click **Reset MFA** to proceed. Resetting a user's MFA immediately signs them out of all sessions. The user will need to sign in again and, if [MFA enforcement](/help/command/tenant/tenant-security) is enabled on the tenant, set up a new authenticator during their next sign-in. ## Removing a User Removing a user permanently deletes them from the tenant and removes all of their associations, including security group memberships and protection policy access. ### From the User List Locate the user in the user list. In the **Actions** column, click the **trash icon** button. A confirmation dialog will appear warning that all associations will be removed. Click **Remove** to proceed. ### From the User Profile Click on the user's row in the user list. Click the **⋮** menu button in the top-right corner of the header card. Click **Remove user** and confirm the action in the dialog. User removal is permanent. The user will lose access to all encrypted files, protection policies, and security groups associated with this tenant. If you need to re-add the user later, you will need to [send a new invitation](/help/command/users/provision-users). ## Managing Your Own Profile When you see your own entry in the user list, the available actions are different: * Clicking the **pencil icon** in the Actions column takes you to your [Account Settings](/help/command/account/profile-management) page. * The **Close Sessions** and **Remove** actions are not available for your own account from the user list. * Opening your own user profile shows a link to **Settings** instead of inline editing on the Manage Profile tab. To manage your own profile, MFA, passkeys, and device sessions, use the dedicated pages under [Account & Authentication](/help/command/account/signing-in). ## Quick Reference | Action | User List | User Profile | | ------------------------------------- | ---------------- | -------------------------- | | **Edit name, email, and nationality** | ✓ (pencil icon) | ✓ (Manage Profile tab) | | **Update profile picture** | — | ✓ (click avatar in header) | | **Close all sessions** | ✓ (monitor icon) | ✓ (⋮ menu) | | **Reset MFA** | — | ✓ (⋮ menu) | | **Remove user** | ✓ (trash icon) | ✓ (⋮ menu) | | **Manage devices** | — | ✓ (Manage Devices tab) | | **Drop the Gate** | — | ✓ (Drop the Gate tab) | ## Troubleshooting Action buttons (edit, close sessions, remove) are only shown for other users — you cannot perform these actions on your own account from the user list. Additionally, you need the **User Management** permission to manage other users. Check your security group membership to confirm you have this permission. The **Reset MFA** option is only available when the user has MFA currently enabled. If the user has not set up MFA, the option will be disabled and appear dimmed. User removal is permanent and cannot be undone from the web panel. You can re-add the user by [sending a new invitation](/help/command/users/provision-users) to their email address. Note that their previous security group memberships and protection policy access will need to be reconfigured manually. Closing sessions signs the user out of the web panel and desktop app. However, if they sign back in before any further action is taken, they will regain access. If you need to permanently block access, use [Drop the Gate](/help/command/anomalous-activity/drop-the-gate-on-users) on the user instead. Check whether a filter is applied. If a **Security Group** filter chip is visible below the search bar, it may be restricting the displayed results. Click the **×** on the filter chip to remove it and see all users. Also verify that you are not on a paginated page — use the pagination controls at the bottom of the table to navigate between pages. Your own profile cannot be edited inline from the User Management page. Click the pencil icon next to your name in the user list, and you will be redirected to your [Account Settings](/help/command/account/profile-management) page where you can update your name, email, and profile picture. # Permissions Source: https://theodosian.com/help/command/users/permissions Understand the granular permission system used to control access across your tenant. Permissions in Theodosian control what actions users can perform within Theodosian Command. Permissions are not assigned directly to individual users — instead, they are assigned to [security groups](/help/command/users/security-groups), and users inherit permissions through their group memberships. This page provides a complete reference of all available permissions, how inheritance works, and how to combine permissions effectively for your team. ## How Permissions Work Theodosian uses a **group-based permission model**: 1. An administrator creates a [security group](/help/command/users/security-groups) and enables one or more permissions on it. 2. Users are added as members of the security group. 3. Each member inherits all permissions enabled on that group. 4. If a user belongs to multiple groups, their effective permissions are the **union** of all permissions across every group they belong to. Permissions are evaluated in real time. When a user's security group membership or a group's permissions are changed, the user's access is updated on their next request. Permissions control access to **administrative features** in Theodosian Command (the web panel). They do not control access to encrypted files — file access is governed by [protection policies](/help/command/protection-policies/overview). ## Permission Inheritance Theodosian uses a **tiered inheritance model** to avoid redundant permission grants. When a higher-tier permission is assigned to a group, lower-tier permissions in the same category are automatically implied at runtime — without needing to be explicitly assigned. The tiers follow this convention: | Tier | Convention | Implies | | ---------- | ---------- | -------------------------- | | **View** | `*.VIEW` | Nothing. Read-only access. | | **Manage** | `*.MANAGE` | `*.VIEW` | | **Delete** | `*.DELETE` | `*.MANAGE` + `*.VIEW` | For example, assigning **Users Delete** to a group automatically grants **Users Manage** and **Users View** at runtime — you do not need to assign all three explicitly. All permission tiers are real, independently assignable permissions in the database. You can assign **Users View** alone to give a group read-only access to the user list, without granting the ability to create, update, or delete users. ### Special Inheritance Rules Some permissions have additional inheritance behaviour beyond the standard tiers: * **Users Security Manage** — implies `USERS.VIEW`. It is a sibling of `USERS.MANAGE`, not implied by it, so it must be granted explicitly if needed alongside manage access. * **Compliance Logs Export** — implies `COMPLIANCE.LOGS.VIEW`. * **DTG Users Admins** — implies `DTG.USERS.STANDARD` + `USERS.VIEW`. * **DTG Users Global Admins** — implies `DTG.USERS.ADMINS` + `DTG.USERS.STANDARD` + `USERS.VIEW`. * **DTG Policies** — implies `POLICIES.VIEW`. * **Security Groups Admins Manage** — implies `SECURITY_GROUPS.MANAGE` + `SECURITY_GROUPS.VIEW`. * **Security Groups Admins Delete** — implies all Security Groups permissions. ## Available Permissions Permissions are grouped by functional area. Each section lists the permissions in that area, their codes, and what they grant access to. *** ### Tenant | Permission | Code | Description | | -------------------------- | ------------------------ | ------------------------------------------------------------------------------ | | **Tenant Manage** | `TENANT.MANAGE` | Manage tenant settings and configuration. | | **Tenant Security Manage** | `TENANT.SECURITY.MANAGE` | Manage tenant-level security settings (session policy, MFA enforcement, etc.). | Tenant permissions have no VIEW tier. There is no read-only access to tenant settings — you either have management access or you do not. *** ### Integrations | Permission | Code | Description | Implies | | ----------------------- | --------------------- | ----------------------------------- | ------------------------------------------- | | **Integrations View** | `INTEGRATIONS.VIEW` | View integrations and their status. | — | | **Integrations Manage** | `INTEGRATIONS.MANAGE` | Create and update integrations. | `INTEGRATIONS.VIEW` | | **Integrations Delete** | `INTEGRATIONS.DELETE` | Delete integrations. | `INTEGRATIONS.MANAGE` + `INTEGRATIONS.VIEW` | *** ### Users | Permission | Code | Description | Implies | | ------------------------- | ----------------------- | ------------------------------------------------------- | ----------------------------- | | **Users View** | `USERS.VIEW` | View users and their details. | — | | **Users Manage** | `USERS.MANAGE` | Create and update users. | `USERS.VIEW` | | **Users Delete** | `USERS.DELETE` | Delete users from the tenant. | `USERS.MANAGE` + `USERS.VIEW` | | **Users Security Manage** | `USERS.SECURITY.MANAGE` | Manage user security settings (MFA, devices, passkeys). | `USERS.VIEW` | **Users Security Manage** is independent of **Users Manage**. A group can be granted the ability to reset MFA and manage devices without being able to edit user profiles or invite new users. *** ### Security Groups | Permission | Code | Description | Implies | Global Admin Only | | --------------------------------- | ------------------------------- | ---------------------------------------------- | ------------------------------------------------- | ----------------- | | **Security Groups View** | `SECURITY_GROUPS.VIEW` | View security groups and their members. | — | No | | **Security Groups Manage** | `SECURITY_GROUPS.MANAGE` | Create and update security groups. | `SECURITY_GROUPS.VIEW` | No | | **Security Groups Delete** | `SECURITY_GROUPS.DELETE` | Delete security groups. | `SECURITY_GROUPS.MANAGE` + `SECURITY_GROUPS.VIEW` | No | | **Security Groups Admins Manage** | `SECURITY_GROUPS.ADMINS.MANAGE` | Create and update admin-level security groups. | `SECURITY_GROUPS.MANAGE` + `SECURITY_GROUPS.VIEW` | **Yes** | | **Security Groups Admins Delete** | `SECURITY_GROUPS.ADMINS.DELETE` | Delete admin-level security groups. | All Security Groups permissions | **Yes** | **Security Groups Admins Manage** and **Security Groups Admins Delete** are restricted to **Global Admin** security groups only. They cannot be assigned to Admin or Standard groups. These permissions allow managing other admin-tier groups, which carries significant trust implications. *** ### Protection Policies | Permission | Code | Description | Implies | | ------------------- | ----------------- | -------------------------------------- | ----------------------------------- | | **Policies View** | `POLICIES.VIEW` | View protection policies. | — | | **Policies Manage** | `POLICIES.MANAGE` | Create and update protection policies. | `POLICIES.VIEW` | | **Policies Delete** | `POLICIES.DELETE` | Delete protection policies. | `POLICIES.MANAGE` + `POLICIES.VIEW` | *** ### Compliance | Permission | Code | Description | Implies | | ----------------------------- | --------------------------- | --------------------------------------------- | ---------------------- | | **Compliance Dashboard View** | `COMPLIANCE.DASHBOARD.VIEW` | View the compliance dashboard and analytics. | — | | **Compliance Logs View** | `COMPLIANCE.LOGS.VIEW` | Browse and search compliance logs and events. | — | | **Compliance Logs Export** | `COMPLIANCE.LOGS.EXPORT` | Export compliance logs. | `COMPLIANCE.LOGS.VIEW` | Compliance permissions are all read-only. They grant visibility into audit data but do not allow modifying tenant settings, users, or policies. *** ### Drop the Gate Drop the Gate (DTG) permissions control who can suspend access for users, policies, and the entire tenant. They have their own escalation tier independent of the standard VIEW/MANAGE/DELETE model. | Permission | Code | Description | Implies | | --------------------------- | ------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------- | | **DTG Users Standard** | `DTG.USERS.STANDARD` | Drop the gate for standard (non-admin) users. | `USERS.VIEW` | | **DTG Users Admins** | `DTG.USERS.ADMINS` | Drop the gate for admin users. | `DTG.USERS.STANDARD` + `USERS.VIEW` | | **DTG Users Global Admins** | `DTG.USERS.GLOBAL_ADMINS` | Drop the gate for global admin users. | `DTG.USERS.ADMINS` + `DTG.USERS.STANDARD` + `USERS.VIEW` | | **DTG Policies** | `DTG.POLICIES` | Drop the gate for protection policies. | `POLICIES.VIEW` | | **DTG Tenant** | `DTG.TENANT` | Drop the gate at tenant level, suspending all access for the entire tenant. | — | **DTG Tenant** is the most powerful Drop the Gate permission. It suspends access for every user in the tenant simultaneously. This permission should be restricted to a very small number of trusted administrators. *** ### Billing | Permission | Code | Description | Implies | | ------------------ | ---------------- | ----------------------------------------- | -------------- | | **Billing View** | `BILLING.VIEW` | View billing information and invoices. | — | | **Billing Manage** | `BILLING.MANAGE` | Manage billing and subscription settings. | `BILLING.VIEW` | *** ## Permissions Reference A complete summary of all 27 permissions: | Permission | Code | Category | Global Admin Only | | ----------------------------- | ------------------------------- | ------------------- | ----------------- | | Tenant Manage | `TENANT.MANAGE` | Tenant | No | | Tenant Security Manage | `TENANT.SECURITY.MANAGE` | Tenant | No | | Integrations View | `INTEGRATIONS.VIEW` | Integrations | No | | Integrations Manage | `INTEGRATIONS.MANAGE` | Integrations | No | | Integrations Delete | `INTEGRATIONS.DELETE` | Integrations | No | | Users View | `USERS.VIEW` | Users | No | | Users Manage | `USERS.MANAGE` | Users | No | | Users Security Manage | `USERS.SECURITY.MANAGE` | Users | No | | Users Delete | `USERS.DELETE` | Users | No | | Security Groups View | `SECURITY_GROUPS.VIEW` | Security Groups | No | | Security Groups Manage | `SECURITY_GROUPS.MANAGE` | Security Groups | No | | Security Groups Delete | `SECURITY_GROUPS.DELETE` | Security Groups | No | | Security Groups Admins Manage | `SECURITY_GROUPS.ADMINS.MANAGE` | Security Groups | **Yes** | | Security Groups Admins Delete | `SECURITY_GROUPS.ADMINS.DELETE` | Security Groups | **Yes** | | Policies View | `POLICIES.VIEW` | Protection Policies | No | | Policies Manage | `POLICIES.MANAGE` | Protection Policies | No | | Policies Delete | `POLICIES.DELETE` | Protection Policies | No | | Compliance Dashboard View | `COMPLIANCE.DASHBOARD.VIEW` | Compliance | No | | Compliance Logs View | `COMPLIANCE.LOGS.VIEW` | Compliance | No | | Compliance Logs Export | `COMPLIANCE.LOGS.EXPORT` | Compliance | No | | DTG Users Standard | `DTG.USERS.STANDARD` | Drop the Gate | No | | DTG Users Admins | `DTG.USERS.ADMINS` | Drop the Gate | No | | DTG Users Global Admins | `DTG.USERS.GLOBAL_ADMINS` | Drop the Gate | No | | DTG Policies | `DTG.POLICIES` | Drop the Gate | No | | DTG Tenant | `DTG.TENANT` | Drop the Gate | No | | Billing View | `BILLING.VIEW` | Billing | No | | Billing Manage | `BILLING.MANAGE` | Billing | No | ## The Global Administrator Group The **Global Administrator** security group is a built-in default group that has **all permissions** enabled, including Global Admin-only permissions. It cannot be edited or deleted, and its permissions cannot be changed. The user who creates the tenant is automatically added to the Global Administrator group. Additional users can be added to this group, but exercise caution — members of this group have unrestricted access to every administrative feature in Theodosian Command, including the ability to manage and delete other admin-level security groups. For most users, it is better to create [custom security groups](/help/command/users/security-groups#creating-a-security-group) with only the specific permissions they need. ## Permission Inheritance Examples ### Standard inheritance A group is assigned **Users Delete** (`USERS.DELETE`). At runtime, members of that group effectively have: | Permission | How granted | | -------------- | ------------------------------------------ | | `USERS.DELETE` | Explicitly assigned | | `USERS.MANAGE` | Implied by `USERS.DELETE` | | `USERS.VIEW` | Implied by `USERS.DELETE` → `USERS.MANAGE` | ### Multiple group membership Consider a user named Alex who belongs to two security groups: * **IT Admins** — Users Manage, Security Groups Manage, Policies Manage * **Compliance Team** — Compliance Dashboard View, Compliance Logs Export Alex's **effective permissions** at runtime: | Permission | Source | | --------------------------- | ----------------------------------------------------- | | `USERS.MANAGE` | IT Admins (explicit) | | `USERS.VIEW` | IT Admins (implied by `USERS.MANAGE`) | | `SECURITY_GROUPS.MANAGE` | IT Admins (explicit) | | `SECURITY_GROUPS.VIEW` | IT Admins (implied by `SECURITY_GROUPS.MANAGE`) | | `POLICIES.MANAGE` | IT Admins (explicit) | | `POLICIES.VIEW` | IT Admins (implied by `POLICIES.MANAGE`) | | `COMPLIANCE.DASHBOARD.VIEW` | Compliance Team (explicit) | | `COMPLIANCE.LOGS.EXPORT` | Compliance Team (explicit) | | `COMPLIANCE.LOGS.VIEW` | Compliance Team (implied by `COMPLIANCE.LOGS.EXPORT`) | Permissions are purely additive. There is no concept of "deny" rules — if any group grants a permission, the user has it regardless of their other memberships. ## Recommended Role Configurations **Group type:** Admin **Assign:** Users Manage, Users Security Manage, Users Delete, Security Groups Manage, Security Groups Delete, Policies Manage, Policies Delete Full user and policy management without billing or compliance access. **Group type:** Standard **Assign:** Compliance Dashboard View, Compliance Logs View, Compliance Logs Export Read-only access to all compliance and audit data. Safe to assign to external auditors. **Group type:** Admin **Assign:** Billing View, Billing Manage Full access to billing and subscription management, nothing else. **Group type:** Admin **Assign:** Users Manage, Users Security Manage, Policies Manage, DTG Users Standard, DTG Users Admins, DTG Policies, Compliance Logs View Broad operational visibility and Drop the Gate capability for incident response. **Group type:** Standard **Assign:** Users View, Users Security Manage Read-only user visibility plus the ability to reset MFA and manage devices — without the ability to create, edit, or delete users. **Group type:** Admin **Assign:** Integrations Manage, Integrations Delete Full control over data connector integrations without access to users, policies, or billing. ## Checking Your Permissions Your current permissions determine which sections of Theodosian Command are visible and accessible to you. If a navigation item or feature is not visible, it is likely because you do not have the required permission. To understand which permissions you have, check which security groups you belong to. Your security group memberships are visible on your user profile in the [User Management](/help/command/users/manage-users) section (viewable by administrators), or you can ask your tenant administrator. ## Best Practices Grant users only the permissions they need for their role. Prefer assigning granular permissions (e.g., **Users View** alone) rather than broad ones (e.g., **Users Delete**) unless the higher tier is genuinely needed. Create security groups that map to job roles or responsibilities in your organization. This makes onboarding new users simple — just add them to the appropriate group. Periodically review security group memberships and permissions to ensure they still reflect your team's responsibilities. Remove users from groups they no longer need. Keep sensitive permissions in separate groups. For example, separate **DTG Tenant** from everyday operational permissions so that tenant-wide lockdown requires deliberate action. ## Troubleshooting Sidebar sections are only visible to users who have the corresponding permission. Ask your tenant administrator to check which security groups you belong to and whether those groups have the required permission enabled. If you need access, the administrator can either add the permission to one of your existing groups or add you to a group that already has it. Some actions require a more specific permission than you might expect. For example, viewing users requires **Users View**, but resetting their MFA requires **Users Security Manage** separately. Check the relevant permission's description to confirm you have the right code assigned, not just a related one. These two permissions are **Global Admin only** — they can only be assigned to security groups of type `global_admin`. If you are trying to assign them to an Admin or Standard group, the assignment will be rejected. These permissions are reserved for groups that already have the highest level of trust in the tenant. A user's effective permissions are the union of all permissions from every security group they belong to, including implied permissions from inheritance. Check all of the user's group memberships and note that higher-tier permissions (e.g., MANAGE, DELETE) automatically imply lower-tier ones (e.g., VIEW). You can view a user's security groups from their profile page in [User Management](/help/command/users/manage-users). The user may belong to another security group that grants the same permission, or a higher-tier permission that implies it through inheritance. Check all of their group memberships. If the user's browser session has cached their previous permissions, ask them to refresh the page. Theodosian provides a fixed set of 27 granular permissions. Custom permission codes cannot be created. However, the granular model gives you fine-grained control — you can combine permissions across multiple security groups to build precisely the access level each role in your organization needs. # Provision Users Source: https://theodosian.com/help/command/users/provision-users Invite and onboard new users into your Theodosian tenant. Provisioning users is the process of adding new team members to your Theodosian tenant so they can access encrypted files, participate in protection policies, and use the desktop app. Users are added by invitation — an administrator sends an invite, and the recipient completes their account setup. You must have the **User Management** permission to invite users. By default, users in the **Global Administrator** security group have this permission. ## How User Provisioning Works When you invite a user to your tenant, Theodosian sends them an email invitation containing a magic link. The invited user clicks the link to verify their identity and join the tenant. No passwords are involved — Theodosian uses [passwordless authentication](/help/command/account/signing-in) for all sign-ins. Once a user accepts the invitation and signs in for the first time, their status changes from **User Never Logged In** to **Active** in the user list. ## Inviting a User In the sidebar, click **Users** to open the User Management page. You will see the full list of users currently in your tenant. Click the **Invite User** button in the top-right corner of the page. The invite dialog will appear. Fill in the following fields: | Field | Required | Description | | ------------- | -------- | ------------------------------------------------------------------------------------------------------------- | | **Email** | Yes | The email address of the user you want to invite. This will be used as their login identity. | | **User Name** | Yes | The display name for the user. This is how they will appear across Theodosian Command and in audit logs. | | **User Type** | No | The type of user being invited. Defaults to **Member** if not specified. See [User Types](#user-types) below. | Click **Send Invite** to dispatch the invitation. Theodosian will send an email to the specified address with a magic link to join the tenant. The dialog will close automatically, and you will see a confirmation notification. ## What the Invited User Receives The invited user will receive an email from Theodosian containing: * The name of the tenant they have been invited to. * A magic link to accept the invitation and sign in. When the user clicks the magic link, they are brought into Theodosian Command and added to the tenant. If MFA enforcement is enabled on the tenant, the user will be prompted to [set up multi-factor authentication](/help/command/account/multi-factor-authentication) on their first sign-in. Before entering the app for the first time, invited users may also be prompted to review and accept the **End User License Agreement (EULA)** and **Services Privacy Policy**. These legal acceptance screens appear only when required for that user. ## User Types When inviting a user, you can specify their type. This controls their access level and the restrictions that apply to them within the tenant. | Type | Description | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Member** | A full tenant member. Can belong to any security group, including admin groups. This is the default type for all invited users. | | **Guest** | A guest user with limited access. Cannot belong to admin or global admin security groups, cannot belong to more than **3 security groups** in total, and is subject to a guest-to-member ratio limit of **3 guests per full member**. | | **External** | An external collaborator. Cannot belong to admin or global admin security groups. | The user type can be changed after provisioning from the user's profile page. However, converting a **Member** to **Guest** or **External** will fail if they currently belong to an admin security group, or if doing so would exceed the guest-to-member ratio. ## User Statuses After inviting a user, you can track their onboarding status in the user list: | Status | Meaning | | ------------------------ | ----------------------------------------------------------------- | | **Active** | The user has accepted the invitation and signed in at least once. | | **User Never Logged In** | The invitation has been sent, but the user has not yet signed in. | ## After Provisioning Once a user has been provisioned, you can: Edit their profile, close their sessions, reset their MFA, or remove them from the tenant. Assign the user to security groups to grant them specific permissions within the tenant. Include the user in protection policies so they can access encrypted files. Monitor which devices the user has signed into and manage their device sessions. ## Billing Impact Each provisioned user counts toward your tenant's subscription seat count. When you invite a new user, your subscription usage is updated accordingly. You can review your current usage on the [Billing Management](/help/command/billing/billing-management) page. ## Troubleshooting The **Invite User** button is only visible to users who have the **User Management** permission. Check your security group membership to confirm you have this permission. If you do not, ask a Global Administrator to either grant you the permission or invite the user on your behalf. Ask the user to check their spam or junk folder. If the email still hasn't arrived after a few minutes, try sending the invitation again by repeating the invite process with the same email address. Make sure you entered the correct email address. This means the user has not yet clicked the magic link in their invitation email and signed in. The status will automatically update to **Active** once they complete their first sign-in. You do not need to take any action. If you sent an invitation to the wrong email address, you can [remove the user](/help/command/users/manage-users) from the user list and send a new invitation to the correct address. The original invitation link will no longer work once the user is removed. Currently, users are invited one at a time through the invite dialog. To add multiple users, repeat the invitation process for each person. # Security Groups Source: https://theodosian.com/help/command/users/security-groups Create and manage security groups to organize users and control permissions across your tenant. Security groups are the foundation of access control in Theodosian. They let you organize users into logical groups and assign permissions that determine what each group of users can do within Theodosian Command. Every user in your tenant can belong to one or more security groups, and their effective permissions are the combined set of permissions from all groups they belong to. You must have the **User Management** permission to create, edit, or delete security groups. By default, users in the **Global Administrator** security group have this permission. ## How Security Groups Work Security groups serve two purposes: 1. **Organize users** — Group team members by role, department, or responsibility (e.g., "IT Admins", "Compliance Team", "Engineering"). 2. **Assign permissions** — Each security group has a set of permissions that control what its members can do in Theodosian Command (e.g., manage users, view compliance logs, manage billing). When a user belongs to multiple security groups, they receive the **union** of all permissions from those groups. For example, if a user is in a group with the **Billing** permission and another group with the **Compliance** permission, they can access both billing and compliance features. For a detailed breakdown of all available permissions, see [Permissions](/help/command/users/permissions). ## Security Group Types Every security group has a **type** that determines its role within the tenant and which users are allowed to join it. | Type | Description | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Global Admin** | System-managed groups with unrestricted access across the entire tenant. Cannot be created, edited, or deleted. Only [Member](/help/command/users/provision-users#user-types) users can belong to these groups. | | **Admin** | Custom administrator groups with elevated permissions. Only [Member](/help/command/users/provision-users#user-types) users can belong to these groups — `guest` and `external` users are not permitted. | | **Standard** | Regular groups for organizing users. Can include members of any user type, including `guest` and `external`. | When creating a security group, the type defaults to **Admin**. Choose **Standard** if you need to include guest or external users in the group. ## Default Security Groups Every tenant comes with one built-in security group that cannot be edited or deleted. | Property | Global Administrator | | --------------- | --------------------------------------------------------------------------- | | **Type** | Global Admin | | **Permissions** | All permissions | | **Editable** | No | | **Members** | The tenant creator is automatically added. Additional members can be added. | The Global Administrator group grants full access to every feature in Theodosian Command. Be selective about which users you add to this group. For most users, create custom security groups with only the permissions they need. ## Viewing Security Groups In the sidebar, click **Security Groups** to open the Security Groups list page. The security groups table displays the following columns: | Column | Description | | ---------------- | ---------------------------------------------------- | | **Name** | The name of the security group. | | **Member Count** | The number of users currently assigned to the group. | | **Permissions** | The number of permissions enabled for the group. | Click on any row to view the group's details. ### Searching Security Groups Type a group name into the **Search security groups...** field at the top of the table. Results update as you type. ## Creating a Security Group On the Security Groups list page, click the **Create Security Group** button in the top-right corner. A multi-step modal will open with a sidebar showing the three setup steps. In the **Group Name** field, enter a descriptive name for the security group (e.g., "IT Administrators", "Compliance Auditors", "Finance Team"). Click **Next** to continue. Choose the **Group Type** for this security group. See [Security Group Types](#security-group-types) for a description of each option. Defaults to **Admin** if not specified. Choose **Standard** if you need guest or external users to be eligible for membership in this group. Admin groups are restricted to full Member users only. Search and select members from the inline list using the checkboxes. Use the search bar to filter by name or email address. The counter at the top of the list shows how many members are currently selected. Adding members during creation is optional. You can always add or remove members later from the group's details page. `guest` and `external` users cannot be added to **Admin** or **Global Admin** groups. If you need to include these user types, use a **Standard** group instead. Additionally, `guest` users cannot belong to more than **3 security groups** in total. Click **Next** to continue. Search and select permissions from the inline list using the checkboxes. Use the search bar to filter by permission name. The counter shows how many permissions are currently selected. Click **Create Security Group** to finish. On success, the modal closes automatically and the Security Groups list refreshes to show the new group. ## Managing a Security Group Click on any security group in the list to open its details page. The details page is organized into two tabs: **Users** and **Permissions**. ### Editing the Group Name Click on the security group in the list to open its details page. Click the **Edit Group** button in the top-right corner of the page. In the dialog that appears, enter the new name for the security group. Click **Save** to apply the change. The page header will update to reflect the new name. The **Edit Group** and **Delete Group** buttons are only shown for custom security groups. Default groups like **Global Administrator** cannot be renamed or deleted. ### Managing Members The **Users** tab displays all current members of the security group in a table with the following columns: | Column | Description | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------- | | **Member** | The user's profile picture, display name, and email address. A **Gate Dropped** badge is shown if the user's gate has been dropped. | | **Email** | The user's email address. | | **Joined** | The date the user was added to this security group. | You can search members by name using the **Search users...** field, and sort alphabetically by clicking the **Member** column header. #### Adding or Removing Members At the top of the Users tab, you will see an **Add or remove members** dropdown. Click it to open the member selection panel. Use the search field to find users. Check or uncheck users to add or remove them from the group. The counter shows how many members are currently selected. Click the **Update Members** button to save the membership changes. The button is only enabled when you have made changes to the member list. ### Managing Permissions The **Permissions** tab displays every available permission in Theodosian, each with a toggle switch indicating whether it is enabled for this group. Each permission shows: * **Name** — The human-readable name of the permission (e.g., "Billing", "User Management"). * **Description** — A brief explanation of what the permission grants access to. * **Toggle** — An on/off switch to enable or disable the permission for this group. #### Updating Permissions On the security group's details page, click the **Permissions** tab. Use the toggle switches to enable or disable individual permissions. You can enable or disable multiple permissions before saving. Click **Update Permissions** at the bottom of the page to apply the changes. For default security groups like **Global Administrator** and **Tenant Member**, the permission toggles are disabled and an information banner is displayed: *"This is a default security group, and does not allow permission changes."* ## Deleting a Security Group Click on the security group you want to delete from the Security Groups list. Click the **Delete Group** button (red) in the top-right corner of the page. A confirmation dialog will appear warning that all associations will be removed. Click **Remove** to permanently delete the security group. Only **Admin** and **Standard** security groups can be deleted. **Global Admin** groups are system-managed and cannot be removed. Deleting a security group removes all member associations. Users who were in the deleted group will lose any permissions that were exclusively granted through that group. If those users are not members of any other security group with the same permissions, they will immediately lose access to the corresponding features. ## Security Group Examples Here are some common security group configurations to help you get started: **Type:** Admin **Permissions:** Users Manage, Users Security Manage, Policies Manage Ideal for IT staff who need to manage users, devices, and protection policies but don't need access to billing or compliance logs. **Type:** Standard **Permissions:** Compliance Dashboard View, Compliance Logs View, Compliance Logs Export Ideal for compliance officers or auditors who need to review audit logs and compliance dashboards but should not manage users or policies. Use Standard type to allow external auditors to be members. **Type:** Admin **Permissions:** Billing View, Billing Manage Ideal for finance staff who manage the organization's subscription and billing details but don't need administrative access. **Type:** Admin **Permissions:** Users Manage, Policies Manage, Compliance Logs View, DTG Users Standard Ideal for security team members who need broad visibility and control but don't manage billing. ## Troubleshooting The button to create security groups is only visible to users who have the **User Management** permission. Check your security group membership to confirm you have this permission. If not, contact a Global Administrator. If the **Edit Group** and **Delete Group** buttons are not visible, the security group is a default group (such as **Global Administrator** or **Tenant Member**) that cannot be modified or deleted. Only custom **Admin** and **Standard** security groups can be edited and deleted. If the toggle switches are disabled, you are viewing a default security group whose permissions are fixed. Create a new custom **Admin** or **Standard** security group if you need a different set of permissions. Guest and external users can only be members of **Standard** security groups. If the group you are trying to add them to is of type **Admin** or **Global Admin**, you will need to either change the user's type to **Member**, or create a new **Standard** group with the appropriate access for that user. When you delete a security group, its members lose any permissions that were granted exclusively through that group. To restore access, either add the user to an existing group that has the needed permissions, or create a new security group with the appropriate permissions and add the user to it. A user's effective permissions are the union of permissions from all security groups they belong to. Check all of the user's security group memberships to identify where the unexpected permissions are coming from. You can see a user's security groups by viewing their profile in [User Management](/help/command/users/manage-users). Permission changes take effect on the user's next page load or API request. Ask the user to refresh their browser. If the issue persists, verify that the security group has the correct permission enabled on the **Permissions** tab. # Encrypting Files Source: https://theodosian.com/help/desktop/daily-use/encrypting-files Encrypt files using the Theodosian Desktop App. You can encrypt any file on your computer by right-clicking it and selecting the Theodosian encryption option. The app encrypts the file in place, replacing the original with a `.theodosian` encrypted file. ## How to Encrypt a File In File Explorer, select one or more files you want to encrypt. You can select multiple files by holding **Ctrl** and clicking each file, or by dragging a selection box around them. Right-click on the selected file(s) and choose **Encrypt With Theodosian** from the context menu. The app begins encrypting your files in the background. You will receive a system notification confirming that your files are scheduled for encryption. In Finder, select one or more files you want to encrypt. You can select multiple files by holding **Cmd** and clicking each file, or by dragging a selection box around them. Right-click on the selected file(s), hover over **Services** in the context menu, and choose **Encrypt With Theodosian**. The app begins encrypting your files in the background. You will receive a system notification confirming that your files are scheduled for encryption. ## What Happens During Encryption When you encrypt a file, the following occurs: 1. **Key generation** — The app requests unique encryption keys from the Theodosian server for each file. 2. **File encryption** — Each file is encrypted using AES-256 encryption. The original file is replaced with an encrypted `.theodosian` file in the same location. 3. **Notification** — Once all files are encrypted, you receive a system notification confirming how many files were successfully encrypted. For example, encrypting a file called `report.pdf` will produce `report.pdf.theodosian` in the same directory. The original `report.pdf` file is removed after encryption completes successfully. Files that are already encrypted (files with a `.theodosian` extension) are automatically skipped if you accidentally include them in a selection. ## Tracking Encryption Progress You can monitor the progress of your encryption by opening the [toolbar](/help/desktop/daily-use/the-toolbar). Click the Theodosian icon in your system tray to see the current encryption workload. The workload panel displays: * **Overall status** — The current phase of the encryption process: *Preparing Encryption*, *Generating Encryption Keys*, or *Encrypting Data*. * **File count** — How many files have been completed out of the total (e.g. "3 / 10 files"). * **Per-file progress** — Each file is listed individually with its name, file size, and a progress percentage. * **Status icons** — A spinning indicator for files in progress, a green checkmark for completed files, and a red icon for any files that failed. Once all files have been encrypted, the workload status changes to show the total number of files encrypted. You can dismiss the completed workload by clicking the **Close** button. ## Batch Encryption You can encrypt multiple files at once by selecting them all before right-clicking. All selected files are grouped into a single encryption workload that you can track together in the toolbar. Each file within the batch is encrypted independently. If one file fails, the remaining files will continue to encrypt normally. ## Notifications The app sends system notifications at key points during encryption: | Notification | When it appears | | --------------------------------- | --------------------------------------------------------------------------- | | **Data scheduled for encryption** | Immediately after you trigger encryption, confirming your files are queued. | | **X File(s) Encrypted** | When all files in the workload have been encrypted successfully. | | **X File(s) Failed Encryption** | When one or more files failed to encrypt. Open the toolbar for details. | ## Requirements * You must be [signed in](/help/desktop/signing-in) to the Theodosian Desktop App. If you attempt to encrypt a file while signed out, you will receive a notification prompting you to sign in. * An active internet connection is required to generate encryption keys from the Theodosian server. ## Troubleshooting **On Windows:** The **Encrypt With Theodosian** option appears in the standard File Explorer context menu. Make sure the app is running and you are signed in. The context menu entries are registered automatically when you sign in and removed when you sign out. **On macOS:** The encryption option appears under the **Services** submenu when you right-click a file in Finder. If you do not see it, make sure you are signed in. The app registers the service after sign-in and may briefly restart once to apply the change. You can also check **System Settings** > **Keyboard** > **Keyboard Shortcuts** > **Services** to ensure the Theodosian services are enabled. Open the [toolbar](/help/desktop/daily-use/the-toolbar) to see which files failed and the specific error message for each. Common causes include: * **Source file not found** — The file may have been moved or deleted after you started the encryption. * **Destination file error** — The app could not write the encrypted file to the same directory. Check that you have write permissions to the folder. * **Key generation error** — There was an issue communicating with the Theodosian server. Check your internet connection and try again. You can dismiss the failed workload and retry encryption by right-clicking the file(s) again. You can restore the original file by [removing the encryption](/help/desktop/daily-use/removing-encryption). Right-click the `.theodosian` file and select **Remove File Encryption** to permanently decrypt it back to its original format. # Opening Encrypted Files Source: https://theodosian.com/help/desktop/daily-use/opening-encrypted-files Open and work on encrypted files using the Theodosian Desktop App. Double-click any `.theodosian` file to securely open it in its default application. The Theodosian Desktop App decrypts the file on-the-fly using a virtual file system — you work with the file as you normally would, and encryption is handled transparently in the background. ## How to Open an Encrypted File Locate the `.theodosian` file in File Explorer (Windows) or Finder (macOS) and double-click it. The Theodosian Desktop App will intercept the request and begin the decryption process. The app contacts the Theodosian server to verify your access permissions and retrieve the necessary decryption keys. This typically takes just a moment. Once decrypted, the file opens automatically in its default application. You can view and edit it as you normally would — the file behaves exactly like an unencrypted file while it is open. The encrypted `.theodosian` file on disk is never modified or replaced during this process. The decrypted version exists only temporarily and is managed by the app's virtual file system. You must be [signed in](/help/desktop/signing-in) with an active internet connection to open encrypted files. If you are not signed in, you will receive a system notification prompting you to sign in first. ## File Sessions Every encrypted file you open creates a **file session** that is tracked in the [toolbar](/help/desktop/daily-use/the-toolbar). File sessions let you monitor which encrypted files are currently open and their current status. Each session displays: * **File name** — The name of the decrypted file. * **Status** — The current state of the session (Open, Encrypting, or Error). * **Last Activity** — How long ago the file was last accessed or modified. * **Last Saved** — How long ago changes were last saved and re-encrypted. If the file is up to date, it will display **Up to date**. ### Session Statuses | Status | Description | | -------------- | ---------------------------------------------------------------------------------------------- | | **Open** | The file is open and ready to use. A green shield icon is displayed. | | **Encrypting** | Changes are being re-encrypted in the background. A loading spinner is displayed. | | **Error** | Something went wrong during the session. A red shield icon is displayed with an error message. | ## Auto Re-Encryption When you save changes to an open encrypted file, the Theodosian Desktop App automatically re-encrypts the updated file in the background. You do not need to manually re-encrypt after editing. The re-encryption process works as follows: 1. You save changes in the application you are working in (e.g. pressing **Ctrl+S** or **Cmd+S**). 2. The desktop app detects the changes and begins re-encrypting the file. 3. The session status briefly changes to **Encrypting** in the toolbar. 4. Once complete, you receive a system notification confirming the file has been re-encrypted. Re-encryption happens automatically each time you save. You can continue working while re-encryption is in progress — there is no need to wait for it to finish. ## Closing a File Session File sessions are closed automatically when you close the file in its native application. When a session closes: 1. Any unsaved changes are re-encrypted. 2. The temporary decrypted file is removed. 3. The session is removed from the toolbar. 4. You receive a system notification confirming the file has been re-encrypted. If re-encryption fails when closing a session, you will receive an error notification prompting you to open the toolbar for more details. ## Waiting for Required Approvals Some protection policies require one or more designated recipients to approve your access request before the file can be opened. When you double-click a file protected by such a policy, the Theodosian Desktop App opens a **Waiting for Required Approvals** window instead of decrypting the file immediately. The waiting window shows: | Element | Description | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | **Countdown** | A live timer showing how long is left for recipients to vote. The administrator who configured the policy chose this duration. | | **Approval counter** | A live "X of Y approvals" tally that updates as recipients vote. | | **In-progress indicator** | A spinner showing that the request is still being reviewed. | | **Warning** | A "Do not close this window" message. Closing the window cancels the request. | Closing the waiting window cancels the approval request server-side. Your access attempt resolves immediately as denied. If you reopen the same file afterwards, a fresh approval request is created and recipients receive a new email. When the request resolves, the waiting window closes and control returns to the protection policy's access control workflow: * **Approved** — the workflow continues down the **true** path of the Email Approvals block. What happens next depends on how the policy is configured — if the block is followed by an Allow Access node, the file opens immediately; if there are additional checks (for example MFA Verification or another Email Approvals block), those run next. * **Denied** or **Timer expires** — the workflow continues down the **false** path of the Email Approvals block. Again, the next step depends on the policy configuration — most policies route the false path to a Deny Access node, in which case an Access Denied window appears. You do not need to refresh or interact with the window while waiting. Updates from recipients are reflected live. Recipients receive an email with a **View Details** link that takes them to the approvals page in Theodosian Command. They can approve or deny from that page. See the [Email Approvals](/help/command/protection-policies/email-approvals) documentation for what the recipient experience looks like. ## Access Denied If you do not have permission to open an encrypted file, the app will display an **Access Denied** window instead of opening the file. This window lists the specific reasons why access was denied. Common reasons for access denial include: * Your account is not a member of the file's [protection policy](/help/desktop/daily-use/protection-policies). * The protection policy's access flow has conditions that your session does not meet. * Your account has been removed from the tenant. If you believe you should have access, contact your Theodosian administrator to review the file's protection policy and your account permissions. ## Platform Differences On Windows, the app uses the **Dokany** virtual file system driver to handle decrypted files transparently. This driver is installed automatically during [installation](/help/desktop/windows/installation). Double-clicking a `.theodosian` file in File Explorer will trigger the Theodosian Desktop App to open it. The file type association is registered during installation. On macOS, the app handles decrypted files through a temporary secure directory. The `.theodosian` file type is registered with macOS during [installation](/help/desktop/macos/installation). Double-clicking a `.theodosian` file in Finder will trigger the Theodosian Desktop App to open it. ## Troubleshooting Make sure the Theodosian Desktop App is running. Check your system tray (Windows) or menu bar (macOS) for the Theodosian icon. If the app is not running, launch it from your Applications folder or Start Menu, then try again. You do not have the required permissions to open this file. The Access Denied window will list the specific reasons. Contact your Theodosian administrator to request access or review the file's protection policy. The encrypted file already has an active session. Check the [toolbar](/help/desktop/daily-use/the-toolbar) to see your open sessions. The file may already be open in another application window. The encrypted file does not match any records for your current session. This can happen if the file was encrypted under a different tenant or if the file has been corrupted. Try [signing out](/help/desktop/signing-out) and signing back in, then try opening the file again. Open the toolbar to check the session status and error details. This can occur if your internet connection was interrupted during re-encryption. Save the file again to trigger a new re-encryption attempt. If the problem persists, contact your administrator. You will receive a notification asking you to sign in. Click the Theodosian icon in your system tray or menu bar, then [sign in](/help/desktop/signing-in) with your account. Once signed in, try opening the file again. # Protection Policies Source: https://theodosian.com/help/desktop/daily-use/protection-policies Set and manage protection policies on your encrypted files. Protection policies control who can access your encrypted files and under what conditions. Using the Theodosian Desktop App, you can apply or remove protection policies directly from your file browser without leaving your desktop. Protection policies are created and configured by your organisation's administrator in the [Theodosian dashboard](/help/command/protection-policies/overview). The desktop app lets you apply existing policies to your encrypted files. ## What Is a Protection Policy? A protection policy is a set of rules that governs access to an encrypted file. When you apply a protection policy to a file, only users who meet the policy's criteria can open that file. Policies can include conditions such as: * Which users or security groups are allowed access. * Access flow requirements that must be satisfied before a file can be opened. * Time-based or context-based restrictions. Without a protection policy, an encrypted file can be opened by any signed-in user in your tenant. Applying a policy restricts access to only those who are authorised. ## Applying a Protection Policy You can apply a protection policy to one or more `.theodosian` encrypted files using the right-click context menu. In File Explorer, select one or more `.theodosian` files that you want to apply a policy to. You can select multiple files by holding **Ctrl** and clicking each file. Right-click on the selected file or files. In the context menu, click **Edit File Protection Policy**. The protection policy window will open, displaying a list of available policies from your organisation. Click the policy you want to apply. The policy will be applied to the selected files. You will receive a system notification confirming the change, and the policy window will close automatically. In Finder, select one or more `.theodosian` files that you want to apply a policy to. You can select multiple files by holding **Cmd** and clicking each file. Right-click on the selected file or files. In the context menu, hover over **Services** and click **Edit File Protection Policy**. The protection policy window will open, displaying a list of available policies from your organisation. Click the policy you want to apply. The policy will be applied to the selected files. You will receive a system notification confirming the change, and the policy window will close automatically. ## The Policy Window When you open the protection policy editor, a small window appears with the following elements: * **File information** — For a single file, the file name is displayed at the top. For multiple files, the window shows the number of files selected (e.g. "3 files selected"). * **Policy list** — All available protection policies from your organisation are listed. You can click any policy to apply it. * **Current policy indicator** — If the selected file already has a policy applied, that policy is highlighted with a checkmark icon so you can see which policy is currently active. * **Remove Policy** — At the bottom of the list, a **Remove Policy** option lets you detach the current policy from the selected files. When multiple files are selected, the current policy indicator is not shown because the files may have different policies applied. ### Keyboard Navigation You can navigate the policy window entirely with your keyboard: * **Arrow Up / Arrow Down** — Move through the list of policies. * **Enter** — Apply the currently highlighted policy, or remove the policy if **Remove Policy** is highlighted. * **Escape** — Close the policy window without making changes. ## Changing a Protection Policy To change the policy on a file that already has one applied, follow the same steps as applying a policy. Select the file, open the protection policy editor, and choose a different policy. The new policy will replace the existing one. ## Removing a Protection Policy To remove a protection policy from one or more encrypted files without removing the encryption itself: Select the `.theodosian` file or files in your file browser. Right-click and select **Edit File Protection Policy** (Windows) or go to **Services** > **Edit File Protection Policy** (macOS). In the policy window, click **Remove Policy** at the bottom of the list. The policy will be detached from the selected files. You will receive a system notification confirming the removal, and the policy window will close automatically. Removing a protection policy means the encrypted file will no longer be restricted by policy rules. Any signed-in user in your tenant will be able to open the file. The file remains encrypted — only the access restrictions are removed. ## Multi-File Selection The protection policy editor supports applying or removing policies on multiple files at once. When you select multiple `.theodosian` files and open the policy editor: * The window header shows the number of files selected instead of a single file name. * Choosing a policy applies it to all selected files in a single operation. * Choosing **Remove Policy** detaches the policy from all selected files. This is useful when you need to update access controls across a batch of files, such as when changing team access or updating project permissions. ## Permissions Editing protection policies requires the appropriate permissions in your organisation's Theodosian tenant. If you do not have permission to manage protection policies, you will see an error dialog when attempting to open the policy editor. If you believe you should have access to manage protection policies, contact your organisation's Theodosian administrator to check your [security group](/help/command/users/security-groups) and [role permissions](/help/command/users/roles-and-permissions). The **Edit File Protection Policy** context menu option is only visible when you are signed in and have policy management permissions. If you do not see this option, it means either you are not signed in or your account does not have the required permissions. ## Troubleshooting This option only appears when: * You are [signed in](/help/desktop/signing-in) to the Theodosian Desktop App. * Your account has policy management permissions. * You have right-clicked on a `.theodosian` encrypted file. On macOS, look under the **Services** submenu in the right-click context menu. On Windows, it appears directly in the context menu. If you are signed in and still do not see the option, contact your administrator to verify your permissions. Your account does not have the required permissions to manage protection policies. Contact your organisation's Theodosian administrator to request access. Your organisation may not have created any protection policies yet. Protection policies are managed in the [Theodosian dashboard](/help/command/protection-policies/overview) by your administrator. Contact them to set up policies for your team. If you pressed **Escape** or clicked outside the window, it may have closed without applying changes. Open the policy editor again and select a policy to apply it. You should see a system notification confirming the change when a policy is successfully applied or removed. Protection policy changes take effect immediately on the server. However, if another user already has the file open in an active session, they may continue working until they close it. The policy will be enforced the next time they attempt to open the file. # Removing Encryption Source: https://theodosian.com/help/desktop/daily-use/removing-encryption Permanently remove encryption from protected files. Removing encryption permanently decrypts a `.theodosian` file and restores it to its original, unencrypted format. Unlike [opening an encrypted file](/help/desktop/daily-use/opening-encrypted-files), which decrypts temporarily while you work, removing encryption is a one-time operation that replaces the encrypted file with the original. Once encryption is removed, the file is no longer protected by Theodosian. Anyone with access to the file on disk can open it without authentication or policy restrictions. Only remove encryption when you are certain the file no longer needs protection. ## Requirements Before you can remove encryption from a file, the following must be true: * You are [signed in](/help/desktop/signing-in) to the Theodosian Desktop App. * You have the required permissions to manage encryption for the file. Your administrator controls these permissions through security groups and roles. * The file is not currently open in another application through an active [open session](/help/desktop/daily-use/opening-encrypted-files). If you do not have the required permissions, you will see an error dialog stating "You do not have permission to remove encryption for this file." Contact your administrator if you believe you should have access. ## How to Remove Encryption In File Explorer, navigate to the `.theodosian` file you want to decrypt permanently. Right-click the `.theodosian` file to open the context menu. Click **Remove File Encryption** from the context menu. The app will begin decrypting the file. The app will retrieve the necessary decryption keys from the Theodosian server, verify your permissions, and decrypt the file. Once complete, you will receive a system notification confirming the encryption has been removed. In Finder, navigate to the `.theodosian` file you want to decrypt permanently. Right-click (or Control-click) the `.theodosian` file to open the context menu. Hover over **Services** in the context menu, then click **Remove File Encryption**. The app will retrieve the necessary decryption keys from the Theodosian server, verify your permissions, and decrypt the file. Once complete, you will receive a system notification confirming the encryption has been removed. On macOS, you can only remove encryption from one file at a time. If you select multiple files and attempt to remove encryption, you will see an error message stating that only single file selection is allowed. ## What Happens When You Remove Encryption When encryption is successfully removed: 1. The app contacts the Theodosian server to retrieve the decryption key and verify your access permissions. 2. The file is decrypted and written to its original format — for example, `report.pdf.theodosian` becomes `report.pdf`. 3. The original `.theodosian` encrypted file is deleted. 4. A system notification confirms that the encryption has been removed. 5. Any [protection policies](/help/desktop/daily-use/protection-policies) previously attached to the file no longer apply, since the file is no longer managed by Theodosian. The restored file will be in the same directory as the original encrypted file. ## Troubleshooting Your account does not have the required permissions to remove encryption. This is controlled by your organisation's administrator through security group roles. Contact your administrator to request the necessary access. The **Remove File Encryption** option only appears when you are signed in and have the required permissions. Make sure you are [signed in](/help/desktop/signing-in) to the app. If you are signed in but still do not see the option, your account may not have the necessary permissions — contact your administrator. On macOS, remember that the option is located under the **Services** submenu in the right-click context menu. On macOS, removing encryption only supports single file selection. Select one file at a time and repeat the process for each file you want to decrypt. Make sure you have an active internet connection — the app needs to communicate with the Theodosian server to retrieve decryption keys and verify permissions. If the problem persists, try [signing out](/help/desktop/signing-out) and signing back in, then attempt the operation again. If you accidentally removed encryption from a file, you can re-encrypt it by right-clicking the restored file and selecting [Encrypt With Theodosian](/help/desktop/daily-use/encrypting-files). Note that any protection policies that were previously attached will need to be [reapplied manually](/help/desktop/daily-use/protection-policies). # The Toolbar Source: https://theodosian.com/help/desktop/daily-use/the-toolbar Navigate the Theodosian Desktop App toolbar and system tray. The toolbar is your central hub for monitoring encryption activity, managing open file sessions, and keeping the app up to date. It runs as a lightweight icon in your system tray (Windows) or menu bar (macOS), always ready in the background. ## The System Tray Icon After signing in, the Theodosian icon appears in your system tray: * **Windows** — Bottom-right corner of your taskbar, in the system tray area. * **macOS** — Top-right corner of your screen, in the menu bar. **Left-click** the icon to toggle the toolbar window open or closed. The toolbar window appears near the tray icon and can be dismissed at any time — the app continues running in the background. **Right-click** the icon to access the tray menu, which contains a **Quit Theodosian** option to fully close the app. On macOS, you can also quit the app using the **Cmd+Q** keyboard shortcut while the toolbar window is focused. ## Toolbar Layout The toolbar window is divided into several sections, from top to bottom: ### Header The top bar displays the Theodosian logo on the left and your **profile menu** on the right. The profile menu shows your profile picture and name. Click your name to open a dropdown that displays: * Your **name** and **email address**. * A **Sign Out** option to end your session. ### Update Banner When a new version of the app is available, a banner appears at the top of the toolbar content area. The banner shows the new version number and an **Update Now** button. Clicking **Update Now** begins the update process immediately. You will receive a system notification confirming that the update is starting. See the update guides for [Windows](/help/desktop/windows/updates) or [macOS](/help/desktop/macos/updates) for more details. ### Encryption Workloads When you [encrypt files](/help/desktop/daily-use/encrypting-files), a workload card appears in the toolbar showing the progress of the encryption operation. Each workload displays: * **Status header** — Shows the current phase of the operation: * **Preparing Encryption** — The workload is queued and about to begin. * **Generating Encryption Keys** — Encryption keys are being created on the server. * **Encrypting Data** — Files are actively being encrypted. * **X File(s) Encrypted** — The workload completed successfully. * **X File(s) Failed Encryption** — One or more files encountered errors. * **File list** — Each file in the workload is listed with: * A **status icon** — A green checkmark for encrypted, a red cross for errors, or a spinner for in-progress. * The **file name**. * The **file size**. * The **progress percentage** while encrypting. * **Progress counter** — While in progress, the header shows how many files have been completed out of the total (e.g. "2 / 5 files"). * **Close button** — Once a workload finishes (successfully or with errors), a **Close** button appears in the header to dismiss the workload card. If a file fails to encrypt, an error message is displayed beneath that file's entry explaining what went wrong. ### Open File Sessions When you [open encrypted files](/help/desktop/daily-use/opening-encrypted-files), each open file appears as a session in the toolbar. The sessions section displays: * **Session count** — The header shows the total number of open sessions (e.g. "3 sessions"). * **File entries** — Each session shows: * A **status icon**: * **Green shield** — The file is open and protected. * **Red shield** — The session encountered an error. * **Spinner** — The file is being re-encrypted after changes. * The **file name**, with an **(Encrypting)** label if re-encryption is in progress. * **Last Activity** — How long ago the file was last modified. * **Last Saved** — How long ago changes were last re-encrypted, or **Up to date** if no pending changes exist. ### Empty State When no encryption workloads are running and no encrypted files are open, the toolbar displays a message: > **No encrypted files open** > Open encrypted files will be displayed here This is the default view and confirms the app is running normally with no active operations. ## Notifications The Theodosian Desktop App uses system notifications to keep you informed of important events, even when the toolbar window is closed. Notifications are sent for: | Event | Notification | | -------------------- | --------------------------------------------------------------------------- | | Sign-in successful | "Verification succeeded" with a welcome message. | | Sign-in required | "Verification failed" prompting you to sign in. | | Encryption started | "Data scheduled for encryption" confirming files are queued. | | Encryption complete | "X File(s) Encrypted" confirming successful encryption. | | Encryption failed | "X File(s) Failed Encryption" with a prompt to open the app for details. | | File re-encrypted | "File Re-Encrypted" when an open file's changes are saved and re-encrypted. | | Re-encryption failed | "File Failed Re-Encryption" with a prompt to open the app for details. | | File already open | A notification that the encrypted file is already open in another session. | | Update available | "New Update Available" with the version number. | You do not need to keep the toolbar window open to receive notifications. The app sends native system notifications as long as it is running in the background. ## Keeping the App Running The Theodosian Desktop App is designed to stay running at all times. It starts automatically when you log in to your computer and remains in the background, ready to handle encryption and decryption requests. * **Closing the toolbar window** does not quit the app — it simply hides the window. Click the tray icon again to reopen it. * **Quitting the app** fully stops all operations, including open file sessions and encryption workloads. Only quit the app if you no longer need to work with encrypted files. If you quit the app while encrypted files are open, those file sessions will be closed. Make sure you have saved your work in all open files before quitting. # macOS Installation Source: https://theodosian.com/help/desktop/macos/installation How to download and install the Theodosian Desktop App on macOS. This guide walks you through downloading and installing the Theodosian Desktop App on macOS. ## Before You Begin Make sure your Mac meets the [macOS system requirements](/help/desktop/macos/system-requirements) before proceeding. ## Download Download the latest version of the Theodosian Desktop App from your organisation's Theodosian dashboard, or from the link provided by your administrator. The installer is provided as a `.dmg` disk image file. ## Installation Steps Double-click the downloaded `.dmg` file to mount the disk image. A Finder window will open showing the Theodosian application. Drag the **Theodosian** app icon into your **Applications** folder. If you are replacing a previous version, confirm that you want to replace the existing copy. Open the **Applications** folder and double-click **Theodosian** to launch the app. On first launch, macOS may display a security prompt because the app was downloaded from the internet. If you see a message saying the app "can't be opened because Apple cannot check it for malicious software", go to **System Settings** > **Privacy & Security**, scroll down, and click **Open Anyway**. When prompted, click **Allow** to enable system notifications. The app uses notifications to inform you about encryption status, sign-in confirmations, and available updates. The Theodosian icon will appear in your menu bar (top-right corner of your screen) and the sign-in window will open automatically. Follow the steps in the [Signing In](/help/desktop/signing-in) guide to sign in with your account. ## What the Installer Sets Up During installation and first sign-in, the following components are configured automatically: * **Theodosian Desktop App** — The main application, installed to your Applications folder. * **File association** — The `.theodosian` file type is registered with macOS so you can double-click encrypted files to open them. * **Menu bar icon** — The app runs as a menu bar application, keeping it accessible without cluttering your Dock. * **Services integration** — Right-click context menu options are registered under the **Services** submenu in Finder for encrypting files and managing protection policies. The app may briefly restart after first sign-in to register the Finder context menu services. This is expected behaviour and only occurs once. ## After Installation Once installed and signed in, the app runs as a lightweight toolbar in your menu bar. You interact with it by: * **Clicking the menu bar icon** to open the toolbar and view open file sessions, encryption progress, and updates. * **Right-clicking files in Finder** and selecting options from the **Services** submenu to encrypt files, edit protection policies, or remove encryption. * **Double-clicking `.theodosian` files** to open them securely. You do not need to keep any windows open — the app works entirely from the menu bar and through Finder integration. See [The Toolbar](/help/desktop/daily-use/the-toolbar) for more details on using the app day-to-day. ## Uninstalling To remove the Theodosian Desktop App: 1. Quit the app by right-clicking the Theodosian icon in your menu bar and selecting **Quit Theodosian** (or pressing **Cmd+Q** with the toolbar open). 2. Open your **Applications** folder. 3. Drag **Theodosian** to the Trash, or right-click it and select **Move to Trash**. 4. Empty the Trash to complete the removal. Uninstalling the app will remove the ability to open `.theodosian` encrypted files on this machine. Make sure any files you need are decrypted before uninstalling. You can remove encryption from files using the [Remove File Encryption](/help/desktop/daily-use/removing-encryption) option. # macOS System Requirements Source: https://theodosian.com/help/desktop/macos/system-requirements System requirements for running the Theodosian Desktop App on macOS. Before installing the Theodosian Desktop App, make sure your Mac meets the following requirements. ## Operating System * **macOS 15.4 (Sequoia)** or later * Apple Silicon (M1, M2, M3, M4) or Intel-based Mac ## Software Dependencies The Theodosian Desktop App uses macOS system services to provide right-click context menu integration for encrypting and managing protected files. No additional third-party drivers or software need to be installed. Unlike the Windows version, the macOS version does not require any additional driver installation. All file session handling is managed natively by the application. ## Network * An active internet connection is required to sign in, encrypt files, open encrypted files, and receive updates. * The app communicates with Theodosian servers over HTTPS. Ensure that outbound traffic to `api.theodosian.com` is not blocked by your firewall or proxy. ## Disk Space * Approximately **100 MB** of free disk space for the application. * Additional temporary space is required when encrypting or decrypting files, proportional to the size of the files being processed. ## Permissions During first launch and after updates, macOS may prompt you to grant the following permissions: * **Notifications** — Required for the app to send you system notifications about encryption status, sign-in confirmations, and available updates. * **Services access** — The app registers itself as a macOS Services provider to add context menu options in Finder. This happens automatically and does not require manual configuration. Standard user permissions are sufficient for both installation and day-to-day use. ## File Associations The installer automatically registers the `.theodosian` file type with macOS. After installation, double-clicking any `.theodosian` file will open it with the Theodosian Desktop App. Right-click context menu options for encrypting files and managing protection policies appear under the **Services** submenu in Finder. These are registered automatically when you sign in. # macOS Updates Source: https://theodosian.com/help/desktop/macos/updates How to update the Theodosian Desktop App on macOS. The Theodosian Desktop App automatically checks for updates in the background and notifies you when a new version is available. Updates are downloaded automatically — you just need to confirm when you are ready to install. ## How Updates Work While you are signed in, the app periodically checks the Theodosian update server for new versions. When an update is available: 1. The update is downloaded automatically in the background. 2. You receive a **system notification** letting you know a new version is available. 3. An **update banner** appears at the top of the toolbar window showing the new version number and an **Update Now** button. Updates do not interrupt your work. The download happens silently, and the update is only installed when you choose to proceed. ## Installing an Update Click the Theodosian icon in your menu bar to open the toolbar window. If an update is available, you will see a banner at the top of the window. Click the **Update Now** button in the update banner. You will receive a system notification confirming the update is starting. The app will install the update and restart automatically. The process typically takes a few seconds. After restarting, the app will return to its normal state. You will need to be signed in to continue working with encrypted files. In most cases, your session will be preserved and you will not need to sign in again. Save your work in any open files before installing an update. Open encrypted file sessions will be closed when the app restarts. ## Services Re-registration After certain updates, the app may need to re-register its Finder context menu services. When this happens, the app will restart once automatically to apply the changes. This is expected behaviour and only takes a moment. If you notice that right-click context menu options such as **Encrypt With Theodosian** or **Edit File Protection Policy** are missing after an update, try signing out and signing back in, or restarting the app from your Applications folder. ## Update Checks The app checks for updates approximately every **15 minutes** while you are signed in. You do not need to manually check for updates — if a new version is available, you will be notified automatically. If you dismiss the update banner by closing the toolbar, it will reappear the next time you open the toolbar or the next time the app checks for updates. ## Troubleshooting Updates are only checked while you are signed in. Make sure you are signed in and that the app is running in your menu bar. Also verify that your network connection allows outbound HTTPS traffic to `api.theodosian.com`. If notifications are still not appearing, check that notifications are enabled for Theodosian in **System Settings** > **Notifications** > **Theodosian**. If an update fails, you will receive a system notification indicating the failure. The app will continue running on your current version. Try again later — the app will re-download the update and notify you when it is ready. Some updates require the app to re-register its Finder services, which triggers an automatic restart. If the context menu options do not appear after the restart, try signing out and signing back in. This will re-register the services with macOS. If your organisation uses managed updates, your administrator controls which versions are approved for deployment. Contact your administrator for more information about your organisation's update policy. # Overview Source: https://theodosian.com/help/desktop/overview An introduction to the Theodosian Desktop App for macOS and Windows. The Theodosian Desktop App is a lightweight application for macOS and Windows that lets you encrypt, open, and manage protected files directly from your desktop. It runs quietly in the background as a toolbar app, accessible from your system tray. There is no complex interface to learn — you interact with it through right-click context menus, double-clicking encrypted files, and a small toolbar window that shows your current activity. ## What You Can Do The desktop app provides five core capabilities: * **Encrypt files** — Right-click any file to encrypt it with Theodosian. The original file is replaced with a `.theodosian` encrypted file. * **Open encrypted files** — Double-click any `.theodosian` file to securely open it in its native application. The file is decrypted on-the-fly while remaining protected on disk. * **Auto re-encryption** — When you edit an open encrypted file, your changes are automatically re-encrypted in the background. There is no need to manually re-encrypt after saving. * **Remove encryption** — Permanently decrypt a file when encryption is no longer needed, restoring it to its original format. * **Set protection policies** — Apply or remove protection policies that control who can access an encrypted file and under what conditions. ## How It Works The desktop app integrates directly with your operating system. On macOS, options appear in the Services menu when you right-click files. On Windows, options appear as context menu entries in File Explorer. When you open an encrypted file, the app retrieves the necessary decryption keys from the Theodosian server, verifies your access permissions, and opens the file in its default application. A virtual file system handles the decryption transparently — you work with the file as you normally would, and the app manages encryption in the background. All encryption and decryption operations require an active internet connection and a signed-in session with your Theodosian account. The desktop app is designed to stay running in the background. You do not need to open it manually before working with encrypted files — it starts automatically and is always ready when you need it. ## The Toolbar Clicking the Theodosian icon in your system tray opens the toolbar window. This is your central hub for monitoring activity: * **Open file sessions** — See which encrypted files are currently open, their status, and when they were last saved. * **Encryption workloads** — Track the progress of files being encrypted, including individual file progress and any errors. * **Updates** — Get notified when a new version of the app is available and install it directly from the toolbar. * **Account** — Access your profile and sign out. ## Getting Started To start using the Theodosian Desktop App: Review the system requirements for [Windows](/help/desktop/windows/system-requirements) or [macOS](/help/desktop/macos/system-requirements) to ensure your machine is compatible. Follow the installation guide for [Windows](/help/desktop/windows/installation) or [macOS](/help/desktop/macos/installation). Open the app and [sign in](/help/desktop/signing-in) with your Theodosian account email. Right-click files to encrypt them, and double-click `.theodosian` files to open them. The app handles the rest. # Signing In Source: https://theodosian.com/help/desktop/signing-in Sign in to the Theodosian Desktop App with your account. You need to sign in to the Theodosian Desktop App before you can encrypt or open protected files. The app uses a magic link sent to your email address — there is no password to remember. ## Sign In Steps Launch the Theodosian Desktop App. If you are not already signed in, the sign-in screen will appear automatically. If the app is already running in the background, click the Theodosian icon in your system tray to open it. Type the email address associated with your Theodosian account into the email field and click **Sign In**. The app will display a **Check your email** confirmation screen. Open your email inbox and look for a sign-in message from Theodosian containing a magic link. Click the magic link in the email to verify your identity. The link will open in your browser and automatically redirect you back to the desktop app. If your email address is associated with a single tenant, the app continues directly with that tenant. If your email is associated with multiple tenants, you will be presented with a list of available tenants. Select the tenant you want to sign in to. Depending on the tenant and your account status, the desktop app may show one or more legal acceptance screens before sign-in completes. Global Administrators may first need to accept updated [Terms of Service](/help/command/legal/terms-of-service). Users may then be asked to accept the [End User License Agreement and Services Privacy Policy](/help/command/legal/user-agreements). If you belong to multiple tenants, these screens appear after you select a tenant. If you belong to a single tenant, they appear automatically before sign-in completes. Once verification is complete, you will see a **Verification succeeded** message. The app will redirect you to the toolbar and you will receive a system notification confirming you are signed in. The app is now ready to use. You can close the toolbar window — the app will continue running in the background from your system tray. ## Manual Verification If the magic link does not open the desktop app automatically, you can verify manually: 1. On the **Check your email** screen, click **Verify manually**. 2. Copy the verification token from the email. 3. Paste it into the token field and click **Verify**. ## Staying Signed In The desktop app remembers your session between restarts. You do not need to sign in again each time you open the app or restart your computer, unless you have explicitly [signed out](/help/desktop/signing-out) or your session has expired. If you attempt to encrypt or open a file while not signed in, you will receive a system notification prompting you to sign in first. ## Troubleshooting Check your spam or junk folder. If the email still hasn't arrived after a minute, go back to the sign-in screen and try again. Make sure you are entering the email address that was invited to your Theodosian tenant. Use the manual verification option described above. Copy the verification token from the email and paste it directly into the app. Magic links expire after a short period. If your link has expired, return to the sign-in screen and request a new one. # Signing Out Source: https://theodosian.com/help/desktop/signing-out How to sign out of the Theodosian Desktop App. Signing out of the Theodosian Desktop App ends your current session and returns you to the sign-in screen. While signed out, you will not be able to encrypt, open, or manage protected files. ## How to Sign Out Click the Theodosian icon in your system tray to open the toolbar window. In the top-right corner of the toolbar, click on your name and profile picture to open the dropdown menu. Click **Sign Out** from the dropdown menu. The app will end your session and display a **Session Closed** confirmation before redirecting you to the sign-in screen. ## What Happens When You Sign Out When you sign out, the following occurs: * All open encrypted file sessions are closed. * Any encryption workloads in progress are stopped. * Your local session data is cleared. * The toolbar window is closed and the sign-in screen is displayed. * Right-click context menu options for encryption and protection policies are removed until you sign in again. The app will continue running in the background from your system tray. Click the tray icon at any time to open the sign-in screen and [sign back in](/help/desktop/signing-in). Make sure you have saved your work in any open files before signing out. Open encrypted file sessions will be closed and any unsaved changes in those files may be lost. ## Session Expiry If your session expires while the app is running, you will be signed out automatically. You will receive a system notification prompting you to sign in again the next time you attempt to open or encrypt a file. To resume working, click the Theodosian icon in your system tray and sign in with your email address. # Windows Installation Source: https://theodosian.com/help/desktop/windows/installation How to download and install the Theodosian Desktop App on Windows. This guide walks you through downloading and installing the Theodosian Desktop App on Windows. ## Before You Begin Make sure your system meets the [Windows system requirements](/help/desktop/windows/system-requirements) before proceeding. ## Download Download the latest version of the Theodosian Desktop App installer from your organisation's Theodosian dashboard, or from the link provided by your administrator. The installer is a single `.exe` file that bundles the Theodosian Desktop App and the required Dokany driver together. ## Installation Steps Double-click the downloaded `.exe` installer file. If prompted by Windows User Account Control (UAC), click **Yes** to allow the installer to make changes to your device. Review the license agreement and accept the terms to continue. The installer will automatically install the Dokany virtual file system driver if it is not already present on your system. This is required for securely opening encrypted files. A system restart may be required after installing Dokany for the first time. The installer will let you know if this is necessary. The installer will copy the application files and register the `.theodosian` file extension with Windows. Once finished, the Theodosian Desktop App will be ready to use. After installation, the Theodosian Desktop App will start automatically. You will see the Theodosian icon appear in your system tray (bottom-right corner of your taskbar). The sign-in window will open for you to [sign in](/help/desktop/signing-in) with your account. ## What the Installer Sets Up During installation, the following components are configured automatically: * **Theodosian Desktop App** — The main application, installed to your Program Files directory. * **Dokany driver** — The virtual file system driver required for opening encrypted files. * **File association** — The `.theodosian` file extension is registered so you can double-click encrypted files to open them. * **Startup entry** — The app is configured to launch automatically when you sign in to Windows, so it is always running in the background and ready to use. ## After Installation Once installed and signed in, the app runs as a lightweight toolbar in your system tray. Right-click context menu options for encrypting files and managing protection policies will appear in File Explorer automatically. You do not need to keep any windows open — the app works entirely from the system tray and through right-click context menus. See [The Toolbar](/help/desktop/daily-use/the-toolbar) for more details on using the app day-to-day. ## Uninstalling To remove the Theodosian Desktop App: 1. Open **Settings** > **Apps** > **Installed apps**. 2. Find **Theodosian** in the list. 3. Click the three-dot menu and select **Uninstall**. 4. Follow the prompts to complete the removal. Uninstalling the app will remove the ability to open `.theodosian` encrypted files on this machine. Make sure any files you need are decrypted before uninstalling. You can remove encryption from files using the [Remove File Encryption](/help/desktop/daily-use/removing-encryption) option. If you also want to remove the Dokany driver, you can uninstall it separately from **Settings** > **Apps** > **Installed apps**. # Windows System Requirements Source: https://theodosian.com/help/desktop/windows/system-requirements System requirements for running the Theodosian Desktop App on Windows. Before installing the Theodosian Desktop App, make sure your Windows machine meets the following requirements. ## Operating System * **Windows 10** (version 1809 or later) or **Windows 11** * 64-bit (x64) architecture ## Software Dependencies The Theodosian Desktop App requires **Dokany** to be installed on your system. Dokany is a virtual file system driver that allows the app to securely open encrypted files in their native applications without writing unencrypted data to disk. Dokany is bundled with the Theodosian installer and will be installed automatically during setup. You do not need to download or install it separately. ## Network * An active internet connection is required to sign in, encrypt files, open encrypted files, and receive updates. * The app communicates with Theodosian servers over HTTPS. Ensure that outbound traffic to `api.theodosian.com` is not blocked by your firewall or proxy. ## Disk Space * Approximately **100 MB** of free disk space for the application and its dependencies. * Additional temporary space is required when encrypting or decrypting files, proportional to the size of the files being processed. ## Permissions * **Administrator privileges** are required during installation to set up Dokany and register the `.theodosian` file association. * Standard user permissions are sufficient for day-to-day use after installation. ## File Associations The installer automatically registers the `.theodosian` file extension with Windows. After installation, double-clicking any `.theodosian` file will open it with the Theodosian Desktop App. Right-click context menu options for encrypting files and managing protection policies are registered automatically when you sign in. # Windows Updates Source: https://theodosian.com/help/desktop/windows/updates How updates work for the Theodosian Desktop App on Windows. The Theodosian Desktop App automatically checks for updates in the background and notifies you when a new version is available. Updates are downloaded automatically — you just need to confirm when you are ready to install. ## How Updates Work While you are signed in, the app periodically checks the Theodosian update server for new versions. When an update is available: 1. The update is downloaded automatically in the background. 2. You receive a **system notification** letting you know a new version is available. 3. An **update banner** appears at the top of the toolbar window showing the new version number and an **Update Now** button. Updates do not interrupt your work. The download happens silently, and the update is only installed when you choose to proceed. ## Installing an Update Click the Theodosian icon in your system tray to open the toolbar window. If an update is available, you will see a banner at the top of the window. Click the **Update Now** button in the update banner. You will receive a system notification confirming the update is starting. The app will install the update and restart automatically. On Windows, updates are installed quietly in the background — you do not need to step through an installer or make any choices. After restarting, the app will return to its normal state. You will need to be signed in to continue working with encrypted files. In most cases, your session will be preserved and you will not need to sign in again. Save your work in any open files before installing an update. Open encrypted file sessions will be closed when the app restarts. ## Update Checks The app checks for updates approximately every **15 minutes** while you are signed in. You do not need to manually check for updates — if a new version is available, you will be notified automatically. If you dismiss the update banner by closing the toolbar, it will reappear the next time you open the toolbar or the next time the app checks for updates. ## Troubleshooting Updates are only checked while you are signed in. Make sure you are signed in and that the app is running in your system tray. Also verify that your network connection allows outbound HTTPS traffic to `api.theodosian.com`. If an update fails, you will receive a system notification indicating the failure. The app will continue running on your current version. Try again later — the app will re-download the update and notify you when it is ready. If your organisation uses managed updates, your administrator controls which versions are approved for deployment. Contact your administrator for more information about your organisation's update policy. # Box Source: https://theodosian.com/help/integrations/cloud/box Integrate Theodosian with Box to automatically encrypt and protect sensitive files across your organization's Box environment. Theodosian integrates with [Box](https://www.box.com) to bring client-side encryption and policy-driven access controls to your cloud-stored files. Whether your organization needs to protect controlled unclassified information (CUI), secure intellectual property, or meet regulatory obligations, Theodosian lets you enforce encryption across your Box environment without disrupting how your teams collaborate. Follow the step-by-step guide to connect Box and start protecting your files. ## Why Integrate Box with Theodosian? Box is widely used to store and share sensitive documents, but cloud storage alone doesn't guarantee that your files are encrypted with keys your organization controls. Theodosian adds a layer of client-side encryption on top of Box, ensuring that files are protected at rest — even from the cloud provider itself. With the Box integration, you get two powerful tools for protecting your data: ### Encryption Automations [Encryption automations](/help/command/data-connectors/encryption-automations) are continuous rules that monitor your Box folders and automatically encrypt files on an ongoing basis. Once a rule is active, Theodosian watches the target drive and folder path for new and existing files, encrypting anything that matches your criteria without manual intervention. * Define rules scoped to specific drives, folder paths, and file types. * Attach a [protection policy](/help/command/protection-policies/overview) so that every encrypted file is automatically governed by your organization's access controls and membership rules. * Theodosian keeps monitoring — new files added to a watched folder are discovered and encrypted automatically. ### Encryption Workloads [Encryption workloads](/help/command/data-connectors/encryption-workloads) are single-run jobs designed to encrypt data that already exists in your Box environment. You browse your connected drives, select the files you need to protect, and Theodosian processes them in bulk. * Ideal for encrypting a backlog of existing files that predate your Theodosian deployment. * Select specific files through an interactive file browser with real-time size and count estimates. * Optionally assign a protection policy to govern access to every file in the workload. * Track each file's progress in real time as it moves through the encryption pipeline. ## Supporting Compliance For organizations operating under strict regulatory frameworks, encrypting files in Box with Theodosian can help satisfy data protection requirements across a range of compliance standards: * **CMMC** — Meet Cybersecurity Maturity Model Certification requirements for protecting CUI by encrypting sensitive files at rest in Box with keys your organization controls. * **ITAR** — Satisfy International Traffic in Arms Regulations obligations by ensuring that export-controlled technical data stored in Box is encrypted and access is restricted to authorized personnel through protection policies. * **DCC** — Align with Defense Counterintelligence and Security Agency requirements for safeguarding controlled information by enforcing encryption and auditable access controls across your Box environment. Every encryption event — whether triggered by an automation rule or a manual workload — is recorded in the Theodosian [audit log](/help/command/compliance/audit-log), providing a complete chain of custody for compliance reporting and audits. ## How It Works Theodosian connects to Box through a secure OAuth authorization flow. Your Box password is never stored — authentication is handled entirely through OAuth tokens. Authorize Theodosian to access your Box account through Box's OAuth consent screen. This creates a secure connection that allows Theodosian to read and write files on your behalf. Set up encryption automations to continuously monitor and encrypt files in targeted folders, or dispatch encryption workloads to bulk-encrypt files that already exist. Assign protection policies to control who can access the encrypted data. Track encryption progress in real time as files move through discovery, queuing, and encryption. Review the audit log for a full record of every encryption event. ## Key Capabilities | Capability | Description | | -------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | **Secure OAuth Connection** | Connect to Box without sharing passwords. Theodosian authenticates through Box's standard OAuth consent flow. | | **Encryption Automations** | Define continuous rules that monitor Box folders and automatically encrypt new and existing files as they appear. | | **Encryption Workloads** | Dispatch one-time bulk encryption jobs to protect files that already exist in your Box drives. | | **Folder & File Type Targeting** | Scope encryption to specific drives, folder paths, and file extensions for precise control over what gets encrypted. | | **Protection Policy Assignment** | Govern who can access encrypted files by linking automations or workloads to Theodosian protection policies. | | **Real-Time Progress Tracking** | Monitor the status of every file as it moves through the encryption pipeline, with live progress updates. | | **Audit & Compliance Logging** | Every encryption event is recorded in the Theodosian audit log for regulatory reporting and compliance audits. | | **Connection Health Monitoring** | View connection status at a glance and re-establish connections if an OAuth token expires or is revoked. | ## Prerequisites Before connecting Box to Theodosian, ensure the following: * You are a member of the **Global Administrator** security group in Theodosian. * You have administrative access to your organization's Box account to authorize the OAuth consent screen. * If you plan to assign protection policies to your encryption automations or workloads, [create those policies](/help/command/protection-policies/creating-a-policy) first. Use a dedicated service account when authorizing the Box connection rather than a personal account. This ensures the connection remains active even if an individual user leaves the organization or changes their password. ## Get Started Ready to connect Box to Theodosian? Head over to the Data Connectors setup guide to authorize your connection and start protecting your files. Authorize Theodosian to access your Box account through a secure OAuth flow. Set up continuous rules to automatically encrypt files in your Box folders. Dispatch one-time jobs to bulk-encrypt existing files in Box. # Dropbox Source: https://theodosian.com/help/integrations/cloud/dropbox Integrate Theodosian with Dropbox to automatically encrypt and protect sensitive files across your organization's Dropbox environment. Theodosian integrates with [Dropbox](https://www.dropbox.com) to bring client-side encryption and policy-driven access controls to your cloud-stored files. Whether your organization needs to protect controlled unclassified information (CUI), secure intellectual property, or meet regulatory obligations, Theodosian lets you enforce encryption across your Dropbox environment without disrupting how your teams collaborate. Follow the step-by-step guide to connect Dropbox and start protecting your files. ## Why Integrate Dropbox with Theodosian? Dropbox is widely used to store and share sensitive documents, but cloud storage alone doesn't guarantee that your files are encrypted with keys your organization controls. Theodosian adds a layer of client-side encryption on top of Dropbox, ensuring that files are protected at rest — even from the cloud provider itself. With the Dropbox integration, you get two powerful tools for protecting your data: ### Encryption Automations [Encryption automations](/help/command/data-connectors/encryption-automations) are continuous rules that monitor your Dropbox folders and automatically encrypt files on an ongoing basis. Once a rule is active, Theodosian watches the target drive and folder path for new and existing files, encrypting anything that matches your criteria without manual intervention. * Define rules scoped to specific drives, folder paths, and file types. * Attach a [protection policy](/help/command/protection-policies/overview) so that every encrypted file is automatically governed by your organization's access controls and membership rules. * Theodosian keeps monitoring — new files added to a watched folder are discovered and encrypted automatically. ### Encryption Workloads [Encryption workloads](/help/command/data-connectors/encryption-workloads) are single-run jobs designed to encrypt data that already exists in your Dropbox environment. You browse your connected drives, select the files you need to protect, and Theodosian processes them in bulk. * Ideal for encrypting a backlog of existing files that predate your Theodosian deployment. * Select specific files through an interactive file browser with real-time size and count estimates. * Optionally assign a protection policy to govern access to every file in the workload. * Track each file's progress in real time as it moves through the encryption pipeline. ## Supporting Compliance For organizations operating under strict regulatory frameworks, encrypting files in Dropbox with Theodosian can help satisfy data protection requirements across a range of compliance standards: * **CMMC** — Meet Cybersecurity Maturity Model Certification requirements for protecting CUI by encrypting sensitive files at rest in Dropbox with keys your organization controls. * **ITAR** — Satisfy International Traffic in Arms Regulations obligations by ensuring that export-controlled technical data stored in Dropbox is encrypted and access is restricted to authorized personnel through protection policies. * **DCC** — Align with Defense Counterintelligence and Security Agency requirements for safeguarding controlled information by enforcing encryption and auditable access controls across your Dropbox environment. Every encryption event — whether triggered by an automation rule or a manual workload — is recorded in the Theodosian [audit log](/help/command/compliance/audit-log), providing a complete chain of custody for compliance reporting and audits. ## How It Works Theodosian connects to Dropbox through a secure OAuth authorization flow. Your Dropbox password is never stored — authentication is handled entirely through OAuth tokens. Authorize Theodosian to access your Dropbox account through Dropbox's OAuth consent screen. This creates a secure connection that allows Theodosian to read and write files on your behalf. Set up encryption automations to continuously monitor and encrypt files in targeted folders, or dispatch encryption workloads to bulk-encrypt files that already exist. Assign protection policies to control who can access the encrypted data. Track encryption progress in real time as files move through discovery, queuing, and encryption. Review the audit log for a full record of every encryption event. ## Key Capabilities | Capability | Description | | -------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | **Secure OAuth Connection** | Connect to Dropbox without sharing passwords. Theodosian authenticates through Dropbox's standard OAuth consent flow. | | **Encryption Automations** | Define continuous rules that monitor Dropbox folders and automatically encrypt new and existing files as they appear. | | **Encryption Workloads** | Dispatch one-time bulk encryption jobs to protect files that already exist in your Dropbox drives. | | **Folder & File Type Targeting** | Scope encryption to specific drives, folder paths, and file extensions for precise control over what gets encrypted. | | **Protection Policy Assignment** | Govern who can access encrypted files by linking automations or workloads to Theodosian protection policies. | | **Real-Time Progress Tracking** | Monitor the status of every file as it moves through the encryption pipeline, with live progress updates. | | **Audit & Compliance Logging** | Every encryption event is recorded in the Theodosian audit log for regulatory reporting and compliance audits. | | **Connection Health Monitoring** | View connection status at a glance and re-establish connections if an OAuth token expires or is revoked. | ## Prerequisites Before connecting Dropbox to Theodosian, ensure the following: * You are a member of the **Global Administrator** security group in Theodosian. * You have administrative access to your organization's Dropbox account to authorize the OAuth consent screen. * If you plan to assign protection policies to your encryption automations or workloads, [create those policies](/help/command/protection-policies/creating-a-policy) first. Use a dedicated service account when authorizing the Dropbox connection rather than a personal account. This ensures the connection remains active even if an individual user leaves the organization or changes their password. ## Get Started Ready to connect Dropbox to Theodosian? Head over to the Data Connectors setup guide to authorize your connection and start protecting your files. Authorize Theodosian to access your Dropbox account through a secure OAuth flow. Set up continuous rules to automatically encrypt files in your Dropbox folders. Dispatch one-time jobs to bulk-encrypt existing files in Dropbox. # Google Drive Source: https://theodosian.com/help/integrations/cloud/google-drive Integrate Theodosian with Google Drive to automatically encrypt and protect sensitive files across your organization's Google Drive environment. Theodosian integrates with [Google Drive](https://www.google.com/drive/) to bring client-side encryption and policy-driven access controls to your cloud-stored files. Whether your organization needs to protect controlled unclassified information (CUI), secure intellectual property, or meet regulatory obligations, Theodosian lets you enforce encryption across your Google Drive environment without disrupting how your teams collaborate. Follow the step-by-step guide to connect Google Drive and start protecting your files. ## Why Integrate Google Drive with Theodosian? Google Drive is widely used to store and share sensitive documents across My Drive and Shared Drives, but cloud storage alone doesn't guarantee that your files are encrypted with keys your organization controls. Theodosian adds a layer of client-side encryption on top of Google Drive, ensuring that files are protected at rest — even from the cloud provider itself. With the Google Drive integration, you get two powerful tools for protecting your data: ### Encryption Automations [Encryption automations](/help/command/data-connectors/encryption-automations) are continuous rules that monitor your Google Drive folders and automatically encrypt files on an ongoing basis. Once a rule is active, Theodosian watches the target drive and folder path for new and existing files, encrypting anything that matches your criteria without manual intervention. * Define rules scoped to specific drives (My Drive or Shared Drives), folder paths, and file types. * Attach a [protection policy](/help/command/protection-policies/overview) so that every encrypted file is automatically governed by your organization's access controls and membership rules. * Theodosian keeps monitoring — new files added to a watched folder are discovered and encrypted automatically. ### Encryption Workloads [Encryption workloads](/help/command/data-connectors/encryption-workloads) are single-run jobs designed to encrypt data that already exists in your Google Drive environment. You browse your connected drives, select the files you need to protect, and Theodosian processes them in bulk. * Ideal for encrypting a backlog of existing files that predate your Theodosian deployment. * Select specific files through an interactive file browser with real-time size and count estimates. * Optionally assign a protection policy to govern access to every file in the workload. * Track each file's progress in real time as it moves through the encryption pipeline. ## Supporting Compliance For organizations operating under strict regulatory frameworks, encrypting files in Google Drive with Theodosian can help satisfy data protection requirements across a range of compliance standards: * **CMMC** — Meet Cybersecurity Maturity Model Certification requirements for protecting CUI by encrypting sensitive files at rest in Google Drive with keys your organization controls. * **ITAR** — Satisfy International Traffic in Arms Regulations obligations by ensuring that export-controlled technical data stored in Google Drive is encrypted and access is restricted to authorized personnel through protection policies. * **DCC** — Align with Defense Counterintelligence and Security Agency requirements for safeguarding controlled information by enforcing encryption and auditable access controls across your Google Drive environment. Every encryption event — whether triggered by an automation rule or a manual workload — is recorded in the Theodosian [audit log](/help/command/compliance/audit-log), providing a complete chain of custody for compliance reporting and audits. ## How It Works Theodosian connects to Google Drive through a secure OAuth authorization flow. Your Google password is never stored — authentication is handled entirely through OAuth tokens issued by Google. Authorize Theodosian to access your Google Drive account through Google's OAuth consent screen. This creates a secure connection that allows Theodosian to read and write files on your behalf across My Drive and any Shared Drives you have access to. Set up encryption automations to continuously monitor and encrypt files in targeted folders, or dispatch encryption workloads to bulk-encrypt files that already exist. Assign protection policies to control who can access the encrypted data. Track encryption progress in real time as files move through discovery, queuing, and encryption. Review the audit log for a full record of every encryption event. ## Key Capabilities | Capability | Description | | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | **Secure OAuth Connection** | Connect to Google Drive without sharing passwords. Theodosian authenticates through Google's standard OAuth consent flow. | | **My Drive & Shared Drive Support** | Encrypt files stored in personal My Drive locations as well as organization-wide Shared Drives. | | **Encryption Automations** | Define continuous rules that monitor Google Drive folders and automatically encrypt new and existing files as they appear. | | **Encryption Workloads** | Dispatch one-time bulk encryption jobs to protect files that already exist in your Google Drive drives. | | **Folder & File Type Targeting** | Scope encryption to specific drives, folder paths, and file extensions for precise control over what gets encrypted. | | **Protection Policy Assignment** | Govern who can access encrypted files by linking automations or workloads to Theodosian protection policies. | | **Real-Time Progress Tracking** | Monitor the status of every file as it moves through the encryption pipeline, with live progress updates. | | **Audit & Compliance Logging** | Every encryption event is recorded in the Theodosian audit log for regulatory reporting and compliance audits. | | **Connection Health Monitoring** | View connection status at a glance and re-establish connections if an OAuth token expires or is revoked. | ## Prerequisites Before connecting Google Drive to Theodosian, ensure the following: * You are a member of the **Global Administrator** security group in Theodosian. * You have administrative access to your organization's Google Workspace or Google account to authorize the OAuth consent screen. * The authorizing account has access to the My Drive and Shared Drive locations you intend to protect. * If you plan to assign protection policies to your encryption automations or workloads, [create those policies](/help/command/protection-policies/creating-a-policy) first. Use a dedicated Google Workspace service account when authorizing the Google Drive connection rather than a personal account. This ensures the connection remains active even if an individual user leaves the organization or loses access to specific Shared Drives. ## Get Started Ready to connect Google Drive to Theodosian? Head over to the Data Connectors setup guide to authorize your connection and start protecting your files. Authorize Theodosian to access your Google Drive account through a secure OAuth flow. Set up continuous rules to automatically encrypt files in your Google Drive folders. Dispatch one-time jobs to bulk-encrypt existing files in Google Drive. # SharePoint Source: https://theodosian.com/help/integrations/cloud/sharepoint Integrate Theodosian with SharePoint to automatically encrypt and protect sensitive files across your organization's SharePoint environment. Theodosian integrates with [SharePoint](https://www.microsoft.com/en-us/microsoft-365/sharepoint/collaboration) to bring client-side encryption and policy-driven access controls to your cloud-stored files. Whether your organization needs to protect controlled unclassified information (CUI), secure intellectual property, or meet regulatory obligations, Theodosian lets you enforce encryption across your SharePoint environment without disrupting how your teams collaborate. Follow the step-by-step guide to connect SharePoint and start protecting your files. ## Why Integrate SharePoint with Theodosian? SharePoint is widely used to store and share sensitive documents across team sites, communication sites, and document libraries, but cloud storage alone doesn't guarantee that your files are encrypted with keys your organization controls. Theodosian adds a layer of client-side encryption on top of SharePoint, ensuring that files are protected at rest — even from the cloud provider itself. With the SharePoint integration, you get two powerful tools for protecting your data: ### Encryption Automations [Encryption automations](/help/command/data-connectors/encryption-automations) are continuous rules that monitor your SharePoint sites and document libraries and automatically encrypt files on an ongoing basis. Once a rule is active, Theodosian watches the target site, library, and folder path for new and existing files, encrypting anything that matches your criteria without manual intervention. * Define rules scoped to specific sites, document libraries, folder paths, and file types. * Attach a [protection policy](/help/command/protection-policies/overview) so that every encrypted file is automatically governed by your organization's access controls and membership rules. * Theodosian keeps monitoring — new files added to a watched library or folder are discovered and encrypted automatically. ### Encryption Workloads [Encryption workloads](/help/command/data-connectors/encryption-workloads) are single-run jobs designed to encrypt data that already exists in your SharePoint environment. You browse your connected sites and document libraries, select the files you need to protect, and Theodosian processes them in bulk. * Ideal for encrypting a backlog of existing files that predate your Theodosian deployment. * Select specific files through an interactive file browser with real-time size and count estimates. * Optionally assign a protection policy to govern access to every file in the workload. * Track each file's progress in real time as it moves through the encryption pipeline. ## Supporting Compliance For organizations operating under strict regulatory frameworks, encrypting files in SharePoint with Theodosian can help satisfy data protection requirements across a range of compliance standards: * **CMMC** — Meet Cybersecurity Maturity Model Certification requirements for protecting CUI by encrypting sensitive files at rest in SharePoint with keys your organization controls. * **ITAR** — Satisfy International Traffic in Arms Regulations obligations by ensuring that export-controlled technical data stored in SharePoint is encrypted and access is restricted to authorized personnel through protection policies. * **DCC** — Align with Defense Counterintelligence and Security Agency requirements for safeguarding controlled information by enforcing encryption and auditable access controls across your SharePoint environment. Every encryption event — whether triggered by an automation rule or a manual workload — is recorded in the Theodosian [audit log](/help/command/compliance/audit-log), providing a complete chain of custody for compliance reporting and audits. ## How It Works Theodosian connects to SharePoint through a secure OAuth authorization flow backed by Microsoft Entra ID (formerly Azure Active Directory). Your Microsoft 365 password is never stored — authentication is handled entirely through OAuth tokens. Authorize Theodosian to access your SharePoint environment through Microsoft's OAuth consent screen. A tenant administrator grants the required permissions, creating a secure connection that allows Theodosian to read and write files across the SharePoint sites and document libraries you've authorized. Set up encryption automations to continuously monitor and encrypt files in targeted sites, libraries, and folders, or dispatch encryption workloads to bulk-encrypt files that already exist. Assign protection policies to control who can access the encrypted data. Track encryption progress in real time as files move through discovery, queuing, and encryption. Review the audit log for a full record of every encryption event. ## Key Capabilities | Capability | Description | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Secure OAuth Connection** | Connect to SharePoint without sharing passwords. Theodosian authenticates through Microsoft's standard OAuth consent flow backed by Microsoft Entra ID. | | **Site & Document Library Support** | Encrypt files stored across team sites, communication sites, and any document library your authorizing account has access to. | | **Encryption Automations** | Define continuous rules that monitor SharePoint sites and libraries and automatically encrypt new and existing files as they appear. | | **Encryption Workloads** | Dispatch one-time bulk encryption jobs to protect files that already exist in your SharePoint environment. | | **Folder & File Type Targeting** | Scope encryption to specific sites, libraries, folder paths, and file extensions for precise control over what gets encrypted. | | **Protection Policy Assignment** | Govern who can access encrypted files by linking automations or workloads to Theodosian protection policies. | | **Real-Time Progress Tracking** | Monitor the status of every file as it moves through the encryption pipeline, with live progress updates. | | **Audit & Compliance Logging** | Every encryption event is recorded in the Theodosian audit log for regulatory reporting and compliance audits. | | **Connection Health Monitoring** | View connection status at a glance and re-establish connections if an OAuth token expires or is revoked. | ## Prerequisites Before connecting SharePoint to Theodosian, ensure the following: * You are a member of the **Global Administrator** security group in Theodosian. * You have a Microsoft 365 tenant administrator (or equivalent privileged role) available to grant the OAuth consent on behalf of your organization. * The authorizing account has access to the SharePoint sites and document libraries you intend to protect. * If you plan to assign protection policies to your encryption automations or workloads, [create those policies](/help/command/protection-policies/creating-a-policy) first. Use a dedicated Microsoft 365 service account when authorizing the SharePoint connection rather than a personal account. This ensures the connection remains active even if an individual user leaves the organization or loses access to specific sites or libraries. ## Get Started Ready to connect SharePoint to Theodosian? Head over to the Data Connectors setup guide to authorize your connection and start protecting your files. Authorize Theodosian to access your SharePoint environment through a secure OAuth flow. Set up continuous rules to automatically encrypt files in your SharePoint sites and libraries. Dispatch one-time jobs to bulk-encrypt existing files in SharePoint. # Overview Source: https://theodosian.com/help/integrations/overview Explore the integrations available for Theodosian and learn what's coming next. Theodosian integrates with the tools your organization already uses, so you can protect your data without changing the way you work. From cloud storage platforms to identity providers, Theodosian's growing library of connectors extends encryption, compliance, and access control across your entire ecosystem. ## Cloud Integrations Theodosian connects to the most popular cloud storage platforms, allowing you to automatically discover, encrypt, and protect files stored in the cloud. Through [Data Connectors](/help/command/data-connectors/data-connectors), administrators can authorize a secure connection to a cloud provider, define encryption automation rules, and monitor workloads as files are encrypted in real time. The following cloud integrations are available today: Connect your Box account to encrypt files across your folders and shared drives. Integrate with Dropbox to apply automated encryption to your stored files. Link Google Drive to protect files across personal and shared drives. Connect SharePoint document libraries for automated encryption across your organization. To learn more about how cloud connectors work, including how to connect a provider, create encryption automation rules, and monitor encryption workloads, see the [Data Connectors](/help/command/data-connectors/data-connectors) documentation. ## Coming Soon We're actively building new connector types that will bring Theodosian's protection capabilities to more of your infrastructure. Here's what's on the roadmap: ### IAM Connectors IAM Connectors will sync with your existing user and security group directories, so you can manage Theodosian access using the identity providers you already rely on. Planned integrations include **Microsoft Entra** and **Okta**. ### SIEM Connectors SIEM Connectors will pipe Theodosian's compliance and audit data directly into your security information and event management platforms. Planned integrations include **Splunk** and **Sumo Logic**. ### Data Classification Connectors Data Classification Connectors will integrate with market-leading data tagging and classification solutions, enabling Theodosian to leverage your existing data sensitivity labels when applying encryption and protection policies. Interested in a specific integration? [Contact us](https://theodosian.com/support) to share your feedback or request early access. # Theodosian Help Source: https://theodosian.com/help/overview Encrypt your data, control access, and maintain compliance across your organization.

Theodosian Help

Encrypt your data, control access, and maintain compliance across your organization.
The web-based administration panel for managing your organization's encryption infrastructure. Configure tenants, invite users, define protection policies, connect cloud storage providers, and monitor compliance. Lightweight apps for macOS and Windows that let your team encrypt, open, and manage protected files directly from their desktop. Runs quietly in the background and integrates with your operating system. Connect Theodosian to the tools your organization already uses. Encrypt files across cloud storage platforms like Box, Google Drive, Dropbox, and SharePoint — with identity, SIEM, and data classification connectors on the way. Get help from the Theodosian team with setup, configuration, or troubleshooting. We're here to help you get the most out of the platform.