>
    Strata Copilot
    Access Scenarios for Code Signing
    Focus
    Focus
    1. Home
    2. Next‑Gen Trust Security
    3. Next-Gen Trust Security
    4. Next-Gen Trust Security Overview
    5. Introduction to the Code Signing Capability
    6. Access Scenarios for Code Signing
    Next‑Gen Trust Security

    Access Scenarios for Code Signing

    Table of Contents

    Access Scenarios for Code Signing

    This topic describes common approaches for configuring TSGs, roles, and built-in accounts to control who can create and manage Signing Keys and who can use them for signing.
    Reviewing these common access scenarios can help you determine the best setup for your team.

    How Access Works in the Code Signing Capability

    There are two distinct types of access in the code signing capability:
    • Managing Signing Keys and built-in accounts requires UI or API access, which is controlled by assigning a role to a user on a TSG.
    • Using Signing Keys for signing requires only the credentials from a built-in account (key credentials and Client ID). No UI or API access is needed. Once a built-in account is authenticated to a TSG, it can use any Signing Key in that TSG.
    Because signing access is scoped to the TSG rather than to individual roles, the only way to restrict which keys a signer can use is to place those keys in a separate TSG.
    A built-in account on a parent TSG can access Signing Keys across all of its child TSGs.

    Scenario 1: Single team, admin-provisioned

    Situation: A small team needs access to the same set of Signing Keys. An administrator handles all setup, and signers do not need access to the UI.
    Setup:
    1. Create Signing Keys in the TSG.
    2. Create a built-in account in the TSG.
    3. Send the built-in account credentials (private key and Client ID) to the signers, or store them in a shared secret manager.
    Signers authenticate the Code Sign Client using the credentials and can use any Signing Key in the TSG. They do not need a role or UI access.

    Scenario 2: Single team, self-service

    Situation: A team needs access to the same set of Signing Keys, but you want signers to create their own built-in accounts rather than sharing credentials provisioned by an admin.
    Setup:
    1. Create a custom role that grants access only to the Built-in Accounts page.
    2. Assign this role to signers on the TSG.
    3. Create Signing Keys in the TSG.
    Signers sign in to Next-Gen Trust Security, create their own built-in accounts, and authenticate the Code Sign Client. Each signer has their own credentials, but they cannot create or manage Signing Keys.

    Scenario 3: Separate key access for different groups

    Situation: You have two groups (for example, a development team and a release engineering team) that each need their own set of Signing Keys. Members of one group should not be able to see or use the other group's keys.
    Setup:
    1. Create a child TSG for each group (for example, "Development Signing" and "Release Signing").
    2. Create the appropriate Signing Keys in each child TSG.
    3. Provision built-in accounts in each child TSG (either admin-provisioned or self-service, as described in Scenarios 1 and 2).
    Because signing access is scoped to the TSG, members of one child TSG cannot use the keys in the other.

    Scenario 4: CI/CD pipeline signing

    Situation: An automated build or CI/CD pipeline needs to sign artifacts. No human interaction with the UI should be required at signing time.
    Setup:
    1. Create a Signing Key in the appropriate TSG.
    2. Create a built-in account in that TSG.
    3. Store the built-in account credentials (private key and Client ID) in the CI/CD system's secret store.
    4. Configure the pipeline to authenticate the Code Sign Client using the stored credentials.
    The pipeline authenticates and signs without any UI access. If the pipeline should only have access to a specific set of keys, place those keys in a dedicated child TSG and create the built-in account there.

    Scenario 5: Separation of duties

    Situation: You want one group of users to create and manage Signing Keys but not use them for signing, and another group to sign but not manage keys.
    Setup:
    1. Create a custom role for key administrators that grants access to the Signing Keys page but not the Built-in Accounts page.
    2. Create a custom role for signers that grants access only to the Built-in Accounts page (or use the admin-provisioned approach from Scenario 1 so signers have no UI access at all).
    3. Assign the appropriate roles to each group on the TSG.
    Key administrators can create and manage Signing Keys but cannot create built-in accounts or sign. Signers can create their own built-in accounts (or receive admin-provisioned credentials) but cannot create or modify Signing Keys.

    © 2026 Palo Alto Networks, Inc. All rights reserved.