Next‑Gen Trust Security
Access Management for New and Migrating Users
Table of Contents
Access Management for New and Migrating Users
Next-Gen Trust Security (NGTS) uses Strata Cloud Manager (SCM) for access control. You manage who can access resources by assigning users to Tenant Service Groups (TSGs) and defining their permissions through roles.
This topic explains how access control works in NGTS. It also explains how NGTS access control differs from the approach in Certificate Management, SaaS.
How Access Management Works in NGTS
If you are new to certificate management in NGTS, your access is governed by two key components working together: Tenant Service Groups (TSGs) and Roles.
- Hierarchical TSGs: Instead of a flat list of teams, your organization operates within a hierarchy. The TSG where NGTS was activated serves as the root level, also known as the parent TSG. Administrators can isolate business units, environments, or departments by explicitly sharing the NGTS instance with child TSGs created under the parent TSG.
- Explicit Instance Sharing: Activation does not cascade automatically. When NGTS is activated at the parent TSG level, administrators must explicitly share the instance with eligible child TSGs in their hierarchy to deploy the product.
- The Data Region Constraint: For sharing to succeed, child TSGs must reside in the exact same data region (e.g., US-EAST) as the parent TSG. The system will prevent you from sharing NGTS with any child TSG located in a different data region to comply with data residency rules.
- Centralized Licensing: License management and SCI usage counts are aggregated and visible only at the parent TSG level. Users operating within a child TSG will not see licensing details, ensuring centralized management.
- Roles: While you may see various predefined roles within the Strata Cloud Manager UI, access in NGTS is managed using two built-in roles: Superuser (full access) and View Only Admin (a guest role for read-only access).
- IMPORTANT: When assigning the Superuser built-in role, you must strictly constrain it to the Next-Gen Trust Security application. Otherwise, the user will inadvertently be granted Superuser access to every application in your entire Strata platform.
- The Access Equation: A user's actual permissions are the exact intersection of the TSG they operate in and the role they are assigned. For example, a user might have a role with full access to manage certificates, but they can only perform those actions on resources within their designated child TSG.
- Resource Sharing and Visibility: Resource visibility is determined by your place in the TSG hierarchy. The parent TSG where the product is activated can see and manage all resources that reside within itself and any child TSGs that the NGTS instance has been explicitly shared with. It cannot see or manage resources that reside in other separate NGTS instances (for example, if you activate NGTS for one TSG in the US and another in Germany, the US instance will not see what is in the Germany instance, and vice versa). Furthermore, the parent TSG can create top-level resources—such as Certificate Authorities (CAs) and Issuing Templates. While Issuing Templates must be selectively shared with child TSGs for users to request certificates, code signing operates differently. Currently, when setting up a Signing Key in a child TSG, users automatically have access to select any supported CA created in the parent TSG (such as Built-in CA, DigiCert, ZTPKI, and MS ADCS) without the administrator needing to explicitly make them available. In all cases, users in a child TSG can consume these shared templates and CAs, but they cannot modify them or view the underlying CA configurations.
If You’re Migrating from Certificate Manager, SaaS
If you are migrating from our legacy Certificate Management, SaaS (CM, SaaS) platform, the old authorization model based on flat teams and simple predefined roles has been completely replaced.
- From "Inviting Users" to Enterprise Identity: In the past, managing tenants involved inviting other users to your tenant account. Now, user identity and tenant management are centralized within SCM. You manage users by assigning them to specific TSGs and binding them to Strata-managed roles.
- The Removal of the "Applications" Feature: In CM, SaaS, the "Applications" feature was heavily used to group certificates and dictate which Resource Owners had access to them. In NGTS, the Applications feature has been entirely removed. Because of the improved RBAC approach, grouping by application is no longer necessary; instead, certificates are assigned to and owned directly by a specific TSG.
- Resource Ownership and Assignment: Resources are no longer tied to individual user attributions (like the old createdBy fields). Instead, ownership is strictly enforced at the TSG level through two primary scenarios:
- Requested or Added Certificates: When a user explicitly adds or issues a certificate (e.g., creates a certificate request) within a TSG, that certificate is automatically owned by the TSG that performed the action.
- Discovered Certificates: Because network discovery configuration is a "parent TSG only" resource, certificates found on your network via discovery enter the system inventory as "Unassigned." They are initially visible to all users across the parent TSG and its child TSGs, but owned by no one. Users in any TSG (parent or child) can then assign these certificates, explicitly transferring ownership and management rights to their specific TSG. If a TSG no longer needs to manage a certificate, they can simply unassign it. The parent TSG can also assign certificates to a child TSG or change the TSG ownership of a given certificate.
Mapping Legacy Certificate Manager, SaaS Roles to NGTS Roles
Because the old predefined Certificate Manager, SaaS roles and Application groupings are retired, you will utilize Strata Cloud Manager's flexible RBAC capabilities to recreate and enhance your access policies. Here is how you can map your old workflows to the new NGTS environment:
| Legacy Certificate Manager, SaaS Role | NGTS Equivalent / Implementation |
|---|---|
| Admin / PKI Admin (Previously: Full read/write over all certs/settings) | Parent TSG Superuser: Assign an administrator to the parent TSG with the built-in "Superuser" role. This grants full read, write, and sharing capabilities across the entire hierarchy. Users in the parent TSG can see and manage all resources, and are responsible for sharing items like Issuing Templates with child TSGs. |
| Resource Owner (Previously: Could manage certs attached to Apps they owned) | Child TSG Superuser: Assign the user to a specific child TSG with the built-in "Superuser" role. By constraining their scope to a specific child TSG, the user will have full control over their resources, matching the legacy Resource Owner experience. They can manage resources within their child TSG and consume shared resources provided by the parent TSG, completely replacing the need for "Applications" assignments. |
| Guest / Read-Only (Previously: View access only) | View Only Admin: Assign users to the built-in "View Only Admin" role. This grants read-only access across the environment and prevents them from accessing create, edit, or delete buttons in the UI, matching the legacy Guest read-only experience. |
| Service Accounts (Previously: Automated API access and integrations) | Strata Service Accounts vs. NGTS Built-in Accounts: If your legacy Resource Owners utilized service accounts in Certificate Manager - SaaS, you must now choose the correct account type based on your integration needs. Use Strata service accounts to invoke NGTS APIs (which pass through the Strata API gateway). Conversely, use NGTS built-in accounts strictly for product-delivered integrations that communicate directly with the NGTS data plane and generally involve non-public APIs. |
Activating NGTS Across Your Organization's TSG Hierarchy
When your organization is ready to start using Next-Gen Trust Security, you must initiate the activation process from the top of your tenant hierarchy. Once activated on the parent TSG, you must then explicitly share the NGTS instance with your eligible child TSGs to deploy the product across your various business units.
Prerequisites
- You must be assigned a Customer Superuser role within Strata Cloud Manager (SCM).
- Your organization's parent TSG must already be created in Strata Cloud Manager (SCM). Child TSGs do not need to be present before activating the parent; they can be created at a later date and granted access through explicit instance sharing at that time.
To activate NGTS across your TSG hierarchy
- Log in to Strata Cloud Manager and ensure you are operating within the parent TSG.
- Activate the NGTS product instance on the parent TSG.
- Explicitly share the NGTS instance with your eligible child TSGs.To do this, navigate to the Activation console and select the parent TSG where NGTS was activated using Secure-Flex Credits. On the far right of the tile representing the NGTS instance, click the vertical ellipses to reveal a menu. Select the option to share the instance, and when the modal pops up, select the new child TSGs to share the NGTS instance with. Ensure that the child TSGs you intend to share with are located in the exact same data region (e.g., Americas) as the parent TSG to comply with data residency rules.
- Verify that the instance was successfully shared.
Adding a New Child TSG to an Active NGTS Environment
As your organization grows and new departments or environments require isolation, you can seamlessly expand your NGTS footprint. Once NGTS is actively running on your parent TSG, you can create new child TSGs in your hierarchy and explicitly share the NGTS instance with them to instantly bring the new business units into the NGTS ecosystem.
Prerequisites
- The parent TSG must already have NGTS activated.
- You must have administrative access in Strata Cloud Manager to create new tenant structures.
To add a new child TSG
- Create the new child TSG within Strata Cloud Manager (SCM) directly under your activated parent TSG.
- Ensure the new child TSG is created in the exact same data region (e.g., Americas) as the parent TSG to comply with data residency rules and allow NGTS capabilities to be successfully shared.
- Explicitly share the NGTS instance with the new child TSG. To do this, navigate to the Activation console and select the parent TSG where NGTS was activated using Secure-Flex Credits. On the far right of the tile representing the NGTS instance, click the vertical ellipses to reveal a menu. Select the option to share the instance, and when the modal pops up, select the new child TSG to share the NGTS instance with.Note: Because cross-region data sharing violates data residency requirements, the system will strictly enforce this boundary. If a child TSG is in a different data region, the system will either prevent you from selecting it in the modal or display an error message.
- Verify that the instance was successfully shared.
Monitoring SCI License Usage Across Your Organization
License consumption in NGTS is strictly centralized to simplify administration. Rather than checking individual child TSGs, administrators can track the aggregate Secure Credential Issuance (SCI) usage across the entire enterprise directly from the parent TSG, ensuring streamlined billing and centralized oversight.
Prerequisites
- You must have a Customer License Administrator or Superuser role.
- NGTS must be actively consuming licenses across one or multiple TSGs.
To monitor SCI license usage
- Log in to the system and verify that your context is set specifically to the parent TSG.
- Navigate to the Licensing page in the UI.
- Review the aggregate SCI usage count. This number represents the total, rolled-up consumption across the parent TSG and all activated child TSGs in your hierarchy.
Note: If you switch your view to a child TSG, you will not see license metrics. The Licensing page is completely hidden from the navigation bar and cannot be viewed.