Skip to main content

Adding NGTS Support to Your Integration

Audience: Technology partners who have built an integration against Certificate Manager SaaS (CM SaaS) and want to add support for Next-Gen Trust Security (NGTS).

This is a single reference for everything you need to update your integration for NGTS, with links to the officially published documentation. Two changes require code updates on your side: the authentication mechanism and the removal of the "Applications" feature. The rest of this guide covers the integration building blocks — issuance, templates, lifecycle, tagging, discovery — so you can map your existing functionality onto NGTS.

Documentation base

All product documentation referenced on this page lives under Next-Gen Trust Security Docs.

What's Different at a Glance​

AreaCM SaaSNGTS
PlatformStandalone SaaSIntegrated into Palo Alto Networks Strata Cloud Manager (SCM)
Identity & accessInvite users to a flat tenantCentralized in SCM; access via Tenant Service Groups (TSGs) + roles
RolesPredefined (Admin, PKI Admin, Resource Owner)Built-in roles plus flexible custom roles, scoped by TSG
Grouping / ownership"Applications" group certificates and dictate accessApplications removed; certificates owned directly by a TSG, organized with tags
API authenticationCM SaaS service accountsStrata service accounts / NGTS built-in accounts

The two items that require integration changes are covered in the next two sections.

Change 1: Authentication​

In NGTS, authentication and access control are handled through Strata Cloud Manager. Machine-to-machine access (APIs, applications, services) uses accounts designed for non-human callers rather than user credentials.

Two account types are relevant to integrations:

  • Strata service accounts — used to invoke NGTS APIs that pass through the Strata API gateway.
  • NGTS built-in accounts — machine accounts within NGTS. These include a Custom API Integration use case that authenticates to NGTS APIs using Workload Identity Federation (WIF). WIF lets your application authenticate with short-lived tokens from a trusted Identity Provider (IdP) instead of managing long-lived API keys.

Which account type applies depends on how your integration calls NGTS. The Palo Alto Networks team will confirm the right path with you during enablement.

Access model to be aware of: a caller's effective permissions are the intersection of the TSG it operates in and the role assigned to it. When you request or create resources, they are owned by the TSG that performed the action.

Calling the API​

NGTS APIs are served from a different base URL than CM SaaS:

https://api.strata.paloaltonetworks.com/ngts

Strata Cloud Manager APIs authenticate using the OAuth 2.0 Client Credentials flow. Use the client_id and client_secret associated with your service account, along with a scope of tsg_id:XXXXXXXXXX, where XXXXXXXXXX is the Tenant Service Group ID. Attach the resulting JWT access token to all API calls as a Bearer token in the Authorization header:

Authorization: Bearer <token>

See the NGTS API Reference for the full endpoint catalog and an interactive authentication walkthrough.

Reference documentation​

Change 2: "Applications" Removed (Use TSGs + Tags)​

In CM SaaS, the Applications feature grouped certificates and dictated which Resource Owners could access them. NGTS removes Applications entirely. Certificates are now owned directly by a Tenant Service Group (TSG), and grouping is done with tags.

How the request flow changes:

CM SaaSNGTS
Set upUsers added to Teams; PKI Admins grant Teams access to Issuing TemplatesAdmins create TSGs; PKI Admins make Issuing Templates available to TSGs
GroupingUser creates an Application, assigns Issuing Templates to itNo Application object; use tags
RequestRequest a certificate for an ApplicationRequest a certificate by specifying an Issuing Template available to the TSG, plus a tag indicating the application it secures
OwnershipApplication (owned by a Team)The TSG that made the request

What to update in your integration: remove any dependency on Applications as an object — creating, referencing, or assigning to them. Replace application-based grouping with tags, and rely on the TSG for ownership and access scoping.

Reference documentation​

Integration Building Blocks​

The core certificate lifecycle capabilities carry over from CM SaaS. Use these references to map your existing functionality onto NGTS.

Certificate issuance & templates​

ACME​

Certificate lifecycle​

Discovery​

Integrations (cloud providers, credential managers)​

Strata Cloud Manager surface​

Migration Checklist​

  • Authentication: Replace CM SaaS service-account authentication with the appropriate NGTS mechanism (Strata service account or NGTS built-in account via Workload Identity Federation). Confirm the account type and required scopes with the Palo Alto Networks team.
  • Remove Applications: Delete any logic that creates, references, or assigns to Applications.
  • Adopt TSGs: Ensure requests operate within the correct TSG; rely on TSG ownership for access.
  • Adopt tags: Where you used Applications to group or label certificates, use tags instead.
  • Certificate requests: Update request calls to specify an Issuing Template available to the TSG (plus tags), rather than an Application.
  • Lifecycle operations: Validate issuance, renewal, revocation, retirement, and inventory retrieval against NGTS.
  • Test end-to-end in the NGTS test environment provided during enablement.

Getting Enabled​

To build and test against NGTS, you'll be provisioned with an NGTS test environment and account access. Reach out to your Palo Alto Networks partner contact to get started, and share the best technical contacts on your side to enable.