Federated Tenants

The Federated Tenants feature provides a collective view of data from configured Child Tenants into a single “umbrella” account. This architecture is designed for Managed Security Service Providers (MSSPs) and large organizations to monitor and manage multiple sub-organizations from a centralized interface, significantly simplifying and accelerating triage and investigation workflows.

Through this centralized view, administrators can:

  • Streamline alert management: Manage and triage alerts from dozens of child tenants in a single queue, allowing for investigation and closure without leaving the Federated Tenant (Parent) account.

  • Accelerate threat hunting: Conduct centralized log searches across the entire organization to quickly identify exposure to specific vulnerability exploits or Indicators of Compromise (IOCs).

  • Maintain operational silos: Drive efficiency at scale while strictly maintaining the necessary data separation and security boundaries at the Child Tenant level.

Activation: The Federated Tenants feature is a specialized configuration. Contact your Corelight account manager to federate existing tenants or add new ones to your organization.

How Federation works

Understanding the structural relationship between account types is essential for maintaining effective security administration and data integrity across your organization.

Account types

  • Federated Tenant (Parent): An aggregate account that provides a collective view of data from all Child Tenants. It is a “passive” layer; it cannot have its own physical or virtual sensors directly attached to it, and it does not ingest its own data directly.

  • Child Tenant (Sub-Tenant): Configured environments that ingest data from their own specific sensors. Users within a Child Tenant can only access data collected specifically for their respective environment.

Data ingestion and access boundaries

To maintain system performance and security, the Federated architecture defines strict rules for how data is captured and viewed across the federation.

  • Limited “downward” access: While Federated Tenant (Parent) users can see the detections, logs, and policies of Child Tenants, they cannot log into a Child Tenant directly unless explicitly added as a user to that specific environment.

  • No “sideways” access: Child Tenants are strictly isolated from one another. A Child Tenant has no access to see or interact with data belonging to any other Child Tenant.

  • No “upward” access: Child Tenant users cannot see Federated Tenant (Parent) users or log into the aggregate account.

  • Data flows up: The Federated Tenant (Parent) can view Child Tenant data. However, it acts only as a shell for managing Child Tenants; it does not ingest its own data or generate its own detections.

  • Changes are bidirectional: Changes made to a Child Tenant’s detections and policies from the Federated Tenant (Parent) view will be reflected locally in the Child Tenant. Conversely, while a Child Tenant user cannot modify the parent configuration, updates they make to their own local detections and policies will automatically be reflected in the aggregate Federated Tenant (Parent) view.

Identity and access rules

  • No duplicate emails: Investigator does not support duplicate email addresses across the system.

  • Sub-addressing requirement: If your organization uses a single SSO, you must use sub-addressing (for example, admin+tenantA@company.com) to ensure the system recognizes you as a unique user for each specific tenant.

Verifying your Federated environment

Use this checklist to complete your initial orientation and verify that you have the necessary access and visibility across your federated environment.

  1. Confirm your identity access

    • Verify login: Ensure you can log into the Federated Tenant account.

    • Check sub-addressing: If you require access to specific Child Tenants for local administration, verify your unique email addresses (for example, user+tenantA@company.com) are active.

  2. Orient to the global view

    • Locate the Tenant menu: Find the Tenant menu available on supported Investigator pages.

    • Toggle to “All Tenants”: Set your view to the aggregate level to see unified data from across the entire organization.

    • Review the Security Overview: Check the Security Overview page for a high-level summary of alerts across all Child Tenants.

  3. Validate data aggregation

    • Inspect the Detections page: Verify that detections from multiple tenants are appearing in a single list.

    • Identify sources: Check for the tenant identifier on individual detections and the system_name tag in the Logs to confirm which Child Tenant the data originated from.

  4. Practice centralized triage

    • Simulate a triage action: Select a test detection and confirm you have the authority to close, suppress, or escalate it to ServiceNow from the Federated Tenant account.

    • Check user assignment limits: Attempt to view assignment options and note that you cannot assign a detection to a user belonging to a different tenant.

  5. Understand operational boundaries

  • Locate the integrations “gap”: Navigate to the configuration area and confirm the Integrations Page is hidden, as these must be managed locally within Child Tenants.

  • Test the Alert Catalog: Open the Alert Catalog and practice using the Tenant menu to switch between specific Child Tenant views, as an aggregate view is not supported for this feature.

Choosing between Federated and Child Tenant views

Use the following to determine if a task should be performed from the Federated Tenant view, or if you must switch to a Child Tenant.

Stay in the Federated Tenant (Parent) Account for:

  • Aggregated hunting: Searching for a specific threat (IOC) across all offices simultaneously.

  • Unified triage: Reviewing alerts from every office in one list and closing “noise” centrally.

  • Federated reporting: Viewing dashboards or audit logs that combine data from the entire organization.

  • Cross-tenant analysis: Comparing the security posture of different offices on a single screen.

Switch to a Child Tenant (Sub-Tenant) Account for:

  • Local configuration: Setting up an integration (for example, ServiceNow) that is unique to that specific office.

  • Sensor troubleshooting: Using “Agentic Triage” to fix or investigate a sensor in that specific office.

  • Tenant management: Updating the display name or managing users for that specific office.

  • API and automation: Generating an API key for local scripts (keys do not exist at the Federated Tenant level).

Determining the correct tenant context

Use the following matrix to determine which account context is required for specific security actions.

Feature / Action

Federated Tenant Admin (Parent)

Child Tenant Admin (Sub-Tenant)

Data Visibility

Provides a unified view of security data across all Child Tenants.

Limited to data from sensors in that specific tenant.

Detection Management

Can close, suppress, or escalate any Child Tenant detection to ServiceNow.

Can manage detections generated within their own respective tenant.

Detection Assignment

Cannot assign detections to users from a different tenant.

Can assign detections to users within their own tenant.

User Management

Displays only users from the Federated Tenant; cannot manage Child Tenant users.

Managed locally; admins must log in to the specific tenant to manage users.

Tenant Naming

View-only; cannot change names from the aggregate view.

Can edit the display name using General Settings.

Integrations

Page is hidden; cannot manage Child Tenant integrations.

Full access to manage integrations locally.

Alert Catalog

View is per-tenant only; must switch views using the Tenant menu to focus on specific Child Tenants.

Direct access to manage alerts specific to the selected tenant.

Account Settings

Not available in the Federated Tenant view.

Managed on a per-tenant basis.

Updating tenant identification

Administrators can customize tenant names to ensure consistent identification across the system. This task must be performed at the Child Tenant level.

  1. Log in to the individual Child Tenant.

  2. Navigate to General Settings | Tenant Settings.

  3. Click the Edit icon for the tenant.

  4. Update the display name and click Save. Tenant names can include text, numbers, and special characters.

Known limitations

While the Federated Tenant provides centralized visibility, there are specific functional differences between the aggregate view and individual Child Tenants. Review the following items to understand how data, settings, and security actions are managed in this environment.

API and identity management

  • API keys: API keys do not exist at the Federated Tenant level. To use API keys for automation, administrators must log in to each individual Child Tenant and generate a key specifically for that environment. This ensures API integrations are strictly tied to the specific data and scope of a single tenant.

Feature and data scope

  • Integrations: The Integrations Page is hidden in the Federated Tenant view. All third-party integrations (for example, ServiceNow, CrowdStrike) must be configured locally within the Child Tenant that owns the data. Once configured on the child, the information generated by the integration is included in the Federated Tenant’s UI.

  • Policy management: The platform does not support “cascading” or global policies. Policies must be managed and edited for each tenant individually via the tenant switcher.

  • Detection IDs: Detections do not have a unique global ID. IDs are only unique within the scope of their specific Child Tenant.

  • Audit transparency: All actions taken by a Federated Tenant Admin are visible to the Child Tenant via their local security audit log.