# OpenCTI Protected Sensitive Configuration: How It Works and How to Manage It

> Secure your OpenCTI platform with protected sensitive configuration. Learn how to manage critical settings like roles and rules, ensuring only authorized users can modify them.

- Repository: [OpenCTI Platform/opencti](https://github.com/opencti-platform/opencti)
- Tags: how-to-guide
- Published: 2026-02-19

---

**OpenCTI's protected sensitive configuration is a security mechanism that locks critical platform settings—such as built-in roles, groups, inference rules, and marking definitions—behind RBAC permissions, rendering them read-only in the UI unless a user possesses the explicit "Allow modification of sensitive configuration" capability.**

The OpenCTI-Platform/opencti repository implements this feature to prevent accidental or malicious changes that could cause data loss, break automations, or affect licensing. By combining static JSON configuration, runtime permission checks, and React-based UI enforcement, the platform creates a "danger zone" that only explicitly authorized administrators can modify.

## What Is Protected Sensitive Configuration?

The **protected sensitive configuration** defines a set of platform options whose alteration carries high operational risk. When enabled, these settings are visually marked in the UI with a red-bordered block and a **Danger zone** chip, and all edit actions are disabled for unauthorized users while keeping the values visible.

By default, the following areas are guarded:

- **Roles & Groups** – Built-in roles (`Administrator`, `Connector`, `Default`) and groups (`Administrators`, `Connectors`, `Default`) are locked to prevent privilege escalation or accidental deletion.
- **Inference Rules** – Activation or deactivation of inference rules that drive automated reasoning.
- **Platform Organization** – Core organization entity settings that anchor the tenant.
- **Marking Definitions** – Pre-defined markings such as TLP and PAP levels (`TLP:CLEAR`, `TLP:GREEN`, `TLP:AMBER`, `TLP:RED`, etc.).
- **Enterprise Edition Toggle** – Enabling or disabling EE features.
- **File Indexing** – Pausing or resetting the file-indexing pipeline.
- **Connector Reset** – Resetting connector state and history.

## Configuration File Structure

The default configuration resides in [`opencti-graphql/config/default.json`](https://github.com/OpenCTI-Platform/opencti/blob/main/opencti-graphql/config/default.json) under the top-level key `protected_sensitive_config`. This JSON object controls which subsystems are protected and which specific entities are included in the protected lists.

```json
{
  "protected_sensitive_config": {
    "enabled": true,
    "markings": {
      "enabled": true,
      "protected_definitions": [
        "TLP:CLEAR",
        "TLP:GREEN",
        "TLP:AMBER",
        "TLP:AMBER+STRICT",
        "TLP:RED",
        "PAP:CLEAR",
        "PAP:GREEN",
        "PAP:AMBER",
        "PAP:RED"
      ]
    },
    "groups": {
      "enabled": true,
      "protected_names": ["Administrators", "Connectors", "Default"]
    },
    "roles": {
      "enabled": true,
      "protected_names": ["Administrator", "Connector", "Default"]
    },
    "rules": { "enabled": true },
    "ce_ee_toggle": { "enabled": true },
    "connector_reset": { "enabled": true },
    "file_indexing": { "enabled": true },
    "platform_organization": { "enabled": true }
  }
}

```

**Key configuration points:**

- Set `"enabled": false` at the root to deactivate the entire protection layer.
- Each sub-object (`markings`, `groups`, `roles`, etc.) can be toggled independently.
- Use `protected_definitions`, `protected_names`, or `protected_ids` to extend the default lists with custom values.
- The configuration is loaded at server start and injected into the GraphQL **Settings** object, making it available to both the front-end and backend resolvers.

## Runtime Enforcement Mechanism

The front-end enforces protection through the custom React hook `useSensitiveModifications`, located in [`opencti-front/src/utils/hooks/useSensitiveModifications.ts`](https://github.com/OpenCTI-Platform/opencti/blob/main/opencti-front/src/utils/hooks/useSensitiveModifications.ts). This hook evaluates both the global settings and the current user's capabilities to determine UI editability.

```typescript
import useAuth from './useAuth';
export type SensitiveConfigType = 
  'ce_ee_toggle' | 'file_indexing' | 'groups' | 'markings' |
  'platform_organization' | 'roles' | 'rules' | 'connector_reset';

const useSensitiveModifications = (type?: SensitiveConfigType, id?: string) => {
  const { me, settings } = useAuth();
  const sensitiveConfig = settings.platform_protected_sensitive_config;

  const isSensitiveConfigEnabled = sensitiveConfig.enabled;
  if (!isSensitiveConfigEnabled) {
    return { isAllowed: true, isSensitive: false };
  }

  const isAllowed = me.can_manage_sensitive_config ?? true;
  let isSensitive: boolean = isSensitiveConfigEnabled;

  if (type && sensitiveConfig[type]) {
    const config = sensitiveConfig[type];
    const protectedIds = config.protected_ids ?? [];
    isSensitive = config.enabled && (!id || protectedIds.includes(id));
  }

  return { isAllowed, isSensitive };
};

```

**Execution flow:**

1. **Read settings** – The hook accesses `settings.platform_protected_sensitive_config` from the GraphQL context.
2. **Global bypass** – If the root `enabled` flag is `false`, the hook returns `{ isAllowed: true, isSensitive: false }`, allowing all modifications.
3. **Capability check** – It verifies `me.can_manage_sensitive_config`, a boolean derived from the user's RBAC capabilities.
4. **Entity-specific validation** – For a given type (e.g., `roles`), it checks if that subsystem is enabled and whether the specific `id` appears in the `protected_ids` list.

UI components consume this hook to conditionally disable inputs:

```tsx
import useSensitiveModifications from '../hooks/useSensitiveModifications';

function RoleNameEditor({ roleId, roleName }) {
  const { isAllowed, isSensitive } = useSensitiveModifications('roles', roleId);

  return (
    <input
      value={roleName}
      disabled={isSensitive && !isAllowed}
      onChange={e => {/* update role */}}
    />
  );
}

```

## Granting Administrator Access

Access to modify protected settings is controlled via **RBAC capabilities**. To grant a user permission to edit sensitive configuration:

1. Navigate to **Settings → Security → Roles → Capabilities** in the OpenCTI UI.
2. Enable the capability **"Allow modification of sensitive configuration"** for the desired role.
3. Assign that role to a group (e.g., *Danger Zone Administrators*) and add the user to that group.

Users inheriting this role will have `me.can_manage_sensitive_config` set to `true`, causing `useSensitiveModifications` to return `isAllowed: true` for all protected entities.

## Customizing or Disabling Protection

Administrators can override the default behavior by modifying the configuration file or injecting environment variables. A restart of the OpenCTI GraphQL service is required for changes to take effect.

**To disable protection entirely**, set the root `enabled` flag to `false` in your configuration override:

```json
{
  "protected_sensitive_config": {
    "enabled": false
  }
}

```

**To customize protected markings and roles** via Docker Compose:

```yaml

# docker-compose.override.yml

services:
  opencti:
    environment:
      - OPENCTI_PROTECTED_SENSITIVE_CONFIG='{
          "enabled": true,
          "roles": {"enabled": true, "protected_names": ["Administrator","Default"]},
          "groups": {"enabled": true, "protected_names": ["Administrators","Connectors"]},
          "markings": {"enabled": true, "protected_definitions": ["TLP:CLEAR","TLP:RED"]} 
        }'

```

**To grant the capability via GraphQL mutation** (for automation or API-based provisioning):

```graphql
mutation AddCapabilityToRole {
  roleEdit(id: "ROLE_ID") {
    edit {
      addCapability(name: "allow-modify-sensitive-configuration")
    }
  }
}

```

## Summary

- The **protected sensitive configuration** in OpenCTI guards high-risk settings like roles, groups, markings, and inference rules from unauthorized modification.
- Configuration is defined in [`opencti-graphql/config/default.json`](https://github.com/OpenCTI-Platform/opencti/blob/main/opencti-graphql/config/default.json) under the `protected_sensitive_config` key, allowing granular control over each protected subsystem.
- Runtime enforcement relies on the `useSensitiveModifications` React hook in [`opencti-front/src/utils/hooks/useSensitiveModifications.ts`](https://github.com/OpenCTI-Platform/opencti/blob/main/opencti-front/src/utils/hooks/useSensitiveModifications.ts), which checks both global settings and the user's `can_manage_sensitive_config` capability.
- Only users with the RBAC capability **"Allow modification of sensitive configuration"** can edit protected items; all other users see these fields as read-only with a "Danger zone" visual indicator.
- Administrators can customize protection lists or disable the feature entirely via JSON configuration or environment variables, followed by a service restart.

## Frequently Asked Questions

### What settings are protected by default in OpenCTI?

By default, OpenCTI protects built-in roles (`Administrator`, `Connector`, `Default`), built-in groups (`Administrators`, `Connectors`, `Default`), standard TLP and PAP marking definitions, inference rules, the platform organization entity, the Enterprise Edition toggle, file indexing controls, and connector reset functions. These are defined in the `protected_sensitive_config` section of the default configuration file.

### How do I enable a user to edit protected sensitive configuration?

Navigate to **Settings → Security → Roles**, select or create a role, and enable the capability **"Allow modification of sensitive configuration"**. Assign this role to the user (directly or via a group). The user will then have the `can_manage_sensitive_config` flag set to `true`, allowing edits to all protected settings.

### Can I customize which markings or roles are protected?

Yes. Modify the `protected_names` array for roles and groups, or the `protected_definitions` array for markings, within the `protected_sensitive_config` JSON object in your configuration file. You can also add specific IDs to `protected_ids` for granular entity-level protection. After updating the configuration, restart the OpenCTI platform to apply the changes.

### What happens if I disable the protected sensitive configuration entirely?

Setting `"enabled": false` at the root of `protected_sensitive_config` bypasses all enforcement logic. The `useSensitiveModifications` hook will return `isAllowed: true` and `isSensitive: false` for all users, effectively removing the "Danger zone" restrictions and allowing any authenticated user to modify previously protected settings. This is not recommended for production environments.