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 Federated Tenant (Parent) configuration, updates they make to their own local detections and policies will automatically be reflected in the aggregate Federated Tenant (Parent) view.

Provisioning requirements and limitations

Before provisioning a new environment or adding tenants to an existing structure, ensure the deployment meets the following capacity, licensing, and regional requirements.

Tenant sizing limitations

These limits apply to all deployments, including individual Child Tenants within a Federated Tenant (Parent) structure:

• Minimum Capacity: Investigator does not support tenants below 1Gbps.

• Maximum Capacity: Provisioning any tenant type exceeding 500Gbps requires three months’ advance notice and approval from Corelight. This limit applies to both standalone deployments and Child Tenants in a Federated Tenant (Parent) structure.

Federated tenant limitations

Federated Tenant (Parent) and Child Tenant deployments are subject to the following regional and licensing constraints:

• Licensing Restrictions: If the Federated Tenant (Parent) is a customer, a Child Tenant cannot be added as a POV (Proof of Value) customer.

• Regional Requirements: The Federated Tenant (Parent) is not supported across multiple regions. All Federated Tenant (Parent) and Child Tenants must reside within the same service region.

Navigating the interface

Investigator pages that support federated views include a Tenant menu. This allows you to toggle between the All Tenants aggregate view or a specific Individual Tenant view. Supporting pages include:

• Dashboard | Security tab: The Highest-risk Entities panel provides aggregate monitoring across the entire system with the ability to switch to individual tenant views.

• Detections page: Unified list of detections from all tenants; each detection identifies its associated Child Tenant in list and detail views.

• Platform Monitoring: The Log Ingest tab displays aggregated log ingest data across all child tenants, with per-tenant metrics and drill-down into individual tenant details. See Federated tenant view.

• Dashboards: Provides a comprehensive view of data on LogScale dashboards across all tenants.

• Logs: Displays logs for all tenants; entries include a system_name tag to identify the specific Child Tenant for LogScale queries.

• Security Audit: Provides both an aggregate view and a per-tenant view of audit logs.

Identity and access rules

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

• Multi-tenant access: A single email address can access multiple tenants. Access to each tenant is based on your IdP group membership and the access configured for your account.

Unified Single Sign-on in Federated Environments

If your organization uses Unified SSO, the SSO configuration is owned by the Federated Tenant (Parent) and shared across all child tenants. You do not need a separate SSO configuration per child tenant.

Users authenticate using a single identity provider (IdP) regardless of which tenant they are accessing.

Tenant Access at Login

When you log in, Investigator places you in the first available tenant. To switch to a different tenant, use the tenant switcher in your profile dropdown in the top navigation bar.

Users may set a Default Tenant in their Account Settings page that will be logged in to on subsequent logins.

Switching tenants

If you have access to multiple tenants, you can switch between them at any time using the tenant switcher in the top navigation bar. If you have access to only one tenant, the Switch Tenant option is not available.

To switch to a different tenant:

1. In the top navigation bar, click your user name.

2. In the profile dropdown, click Switch Tenant.

3. In the tenant list, click the tenant you want to switch to. Each row shows the tenant name and your assigned role. A checkmark indicates your current tenant. To find a specific tenant, type in the search field to filter the list.

4. Wait for the confirmation message. Investigator displays a Successfully switched notification when the switch is complete.

Setting your default tenant

Your default tenant is the tenant Investigator logs you into automatically when you sign in. You can set or change it at any time in your Account Settings.

To set your default tenant:

1. In the top navigation bar, click your user name.

2. Click Account Settings.

3. Under User Profile, open the Default Tenant dropdown and select the tenant you want to be automatically logged into.

4. Click Save.

Note

The Default Tenant dropdown is only visible if you have access to more than one tenant.

Per-Tenant Role Mappings

Each member tenant manages its own role mappings independently. This allows granular permission management to member tenants. To configure role mappings for a member tenant, switch into the member tenant and navigate to System Settings | Users & Access | Access. The Access tab displays a panel to modify SAML role mappings for that tenant only. The IdP connection is inherited from the parent tenant and cannot be changed at the child tenant level. For more information, see Federated Environments in the Configuring SAML SSO topic.

Org-Level Administrator Access

Optional: Federated Tenant (Parent) administrators can request to have Admin access in all child tenants. This is managed by Investigator and does not require separate IdP group membership or role mapping configuration in each child tenant.

Inherited parent admins appear in the Users tab of each child tenant but cannot be edited or deleted locally. Their access is managed from the Federated Tenant (Parent).

Note

Contact your Corelight Account Manager to have Org-level administrator access turned on.

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 (Parent) account.

   • Switch to a child tenant: If you require access to specific Child Tenants for local administration, use the tenant switcher in the top navigation bar. Click your user name, then click Switch Tenant to open the tenant switcher. Search for or select the tenant you want to access.

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 (Parent) 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 Tenant (Parent) and Child Tenant Views

Use the following to determine if a task should be performed from the Federated Tenant (Parent) 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 tenants simultaneously.

• Unified triage: Reviewing alerts from every tenant 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 tenants 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 tenant.

• Agentic Triage: Investigating high-risk entities and detections within that specific tenant.

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

• API and automation: Generating an API key for local scripts (keys do not exist at the Federated Tenant (Parent) 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 (Parent) Admin	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 current tenant (Parent); 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.

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 (Parent) 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 (Parent) 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 (Parent) 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 (Parent) Admin are visible to the Child Tenant via their local security audit log.