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

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 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.

{
  "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. This hook evaluates both the global settings and the current user's capabilities to determine UI editability.

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:

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:

{
  "protected_sensitive_config": {
    "enabled": false
  }
}

To customize protected markings and roles via Docker Compose:

# 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):

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 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, 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}