11.3 Next-Generation Trust Security (NGTS) & Certificate Lifecycle
Key Takeaways
- Palo Alto Networks introduced Next-Generation Trust Security on 23 March 2026 as the first network-native platform unifying certificate lifecycle management with real-time network visibility and enforcement.
- NGTS delivers three capabilities that map to blueprint task 3.4: increased visibility into where digital trust exists, operational resilience through automatic credential refresh before expiry, and cryptographic agility for the post-quantum transition.
- NGTS integrates CyberArk machine identity intelligence into the network; the separately announced Idira platform governs human, machine, and AI-agent identities, while user single sign-on remains the Cloud Identity Engine's role.
- The 47-day certificate lifetime is an industry baseline that makes automation mandatory, not a PAN-OS setting; public certificate validity has already shrunk by more than 90%.
- An expired firewall device certificate removes the firewall from Strata Cloud Manager and stops cloud-delivered lookups while the data plane keeps forwarding traffic normally — a silent failure mode worth recognising.
11.3 Next-Generation Trust Security (NGTS) & Certificate Lifecycle
The Newest Item on the Blueprint
Blueprint task 3.4 reads: "Explain how Next-Generation Trust Security (NGTS) supports identity governance, trust relationships, and adaptive security decisions across the enterprise platform." NGTS is also named in the datasheet's target audience as one of the product families a NetSec-Pro candidate administers. It is the newest addition to the blueprint and the one least covered by third-party study material.
Palo Alto Networks introduced Next-Generation Trust Security on 23 March 2026, describing it as the industry's first network-native platform that unifies certificate lifecycle management (CLM) with real-time network visibility and enforcement.
The Problem NGTS Solves
Enterprises have two separate teams that never used to talk: the team that issues and tracks certificates, and the team responsible for keeping services online. When a certificate expires unnoticed, the second team finds out from an outage.
Three forces made that arrangement untenable:
- Certificate lifetimes collapsed. Public TLS certificate validity has shrunk by more than 90%, and the industry is moving toward a mandatory 47-day renewal cycle. A process that worked at 398 days, or even 90, cannot be executed by hand every six weeks across thousands of endpoints.
- Machine identities exploded. Every workload, container, service account, API client, and now every AI agent needs a credential. Machine identities vastly outnumber human ones and are created and destroyed continuously.
- Cryptography itself is changing. The migration to post-quantum algorithms (section 11.4) requires the ability to re-issue and swap credentials at scale, which is impossible without automation already in place.
Exam Trap Alert: The 47-day figure is an industry certificate-lifetime baseline, not a Palo Alto Networks product setting or a PAN-OS default. It is the reason automation is required, not a value you configure.
What NGTS Delivers
The announcement frames three capabilities, and they map cleanly onto the three verbs in blueprint task 3.4.
| Capability | What it does | Blueprint phrase it serves |
|---|---|---|
| Increased visibility | Identifies where digital trust exists across network services and applications, exposing hidden certificates and blind spots | "trust relationships" |
| Operational resilience | Automatically identifies and refreshes credentials before expiration disrupts services or customer transactions | "identity governance" |
| Cryptographic agility | Enables the transition to post-quantum encryption standards with automated lifecycle management for accelerated renewal cycles | "adaptive security decisions" |
Why "Network-Native" Is the Differentiator
Conventional certificate lifecycle management tools discover certificates by scanning hosts and querying CAs. They find what they are pointed at. A next-generation firewall, by contrast, already sees every TLS handshake on the network — including the certificate presented by a forgotten server that no asset inventory records and no CA account owns.
Making CLM network-native means the discovery surface becomes "every certificate actually in use" rather than "every certificate someone remembered to register." That is what the announcement means by eliminating hidden certificates and blind spots, and it is why the capability lives in the network security platform rather than beside it.
The CyberArk Connection
NGTS integrates CyberArk's machine identity intelligence into the network, closing the gap between the teams that manage certificates and the teams responsible for uptime. Palo Alto Networks also introduced Idira, a next-generation identity security platform that secures every identity in the AI enterprise — human, machine, and AI agent — on a single control plane that discovers risk, applies privilege dynamically, and governs the full lifecycle from first access to last session.
For exam purposes, keep the scopes distinct: NGTS is about machine and cryptographic trust (certificates, keys, machine identities). Idira is the identity security platform spanning human, machine, and AI-agent privilege. Neither is a user single-sign-on product — that is the Cloud Identity Engine's role (section 6.2).
Trust Relationships Inside PAN-OS
"Trust relationships" is not an abstract phrase on this exam. The platform you administer depends on a specific set of certificate constructs, and NetSec-Pro expects you to know which one breaks what.
| Construct | Where configured | What depends on it | Failure symptom |
|---|---|---|---|
| Forward Trust certificate | Device > Certificate Management > Certificates | SSL Forward Proxy for servers with a trusted certificate | Browser certificate warnings on every decrypted site |
| Forward Untrust certificate | Same | SSL Forward Proxy for servers whose certificate the firewall does not trust | Users cannot distinguish untrusted sites from trusted ones |
| Server certificate + private key | Imported to the firewall | SSL Inbound Inspection | Inbound decryption silently fails |
| Certificate Profile | Device > Certificate Management > Certificate Profile | GlobalProtect, Authentication Portal, administrator authentication, IKE peer authentication | Authentication failures, often after a CA rotation |
| SSL/TLS Service Profile | Same area | Management web interface, GlobalProtect portal and gateway, Authentication Portal | Weak-cipher findings, or portal unreachable |
| Device certificate | Retrieved from the Customer Support Portal | mTLS registration to Strata Cloud Manager, Panorama, and cloud services | Firewall drops out of cloud management |
| CRL / OCSP | Within a Certificate Profile | Revocation checking for all of the above | Revoked certificates continue to be accepted, or sessions fail closed |
Exam Trap Alert: The firewall's device certificate — the one used for mutual TLS to Strata Cloud Manager and cloud services — is a frequent silent failure. When it expires, the firewall keeps passing traffic perfectly while disappearing from cloud management and stopping cloud-delivered lookups. Symptom-based questions about a firewall that "went missing from SCM but is still forwarding traffic" point here.
Adaptive Security Decisions
The third phrase in task 3.4 is where trust becomes enforcement. Certificate and identity posture is not just inventory — it feeds policy:
- Decryption profiles terminate sessions whose server certificate is expired, whose issuer is untrusted, or which use unsupported protocol versions and algorithms (sections 3.3 and 3.4).
- HIP-based Security rules grant or deny access based on endpoint posture at connection time (section 9.2).
- Cloud Identity Engine group membership changes propagate to policy without waiting for firewall cache expiry (section 6.2).
- Device-ID objects allow policy to follow a device's identity rather than its address (section 4.4).
Each is a decision made from current trust state rather than from a static allow-list, which is the operational meaning of "adaptive."
Operating Certificate Lifecycle Well
Whether or not an organisation licenses NGTS, the practices the exam expects you to recognise are the same:
1. INVENTORY - discover every certificate in use, including ones no CA account owns
2. OWN - assign an accountable owner and a renewal path to each one
3. AUTOMATE - issue and renew through protocols such as ACME or EST, not tickets
4. SHORTEN - move to short-lived certificates so renewal is exercised constantly
5. MONITOR - alert on approaching expiry, unexpected issuers, and weak algorithms
6. ROTATE - rehearse emergency mass re-issuance before you need it
Step 4 is counter-intuitive and worth internalising: shortening certificate lifetimes increases reliability, because a renewal path exercised every few weeks is a path that demonstrably works, whereas an annual renewal is a manual procedure nobody has practised since the last person who ran it left. Step 6 is what makes the post-quantum migration in the next section survivable — an organisation that can already re-issue its estate on demand can swap algorithms; one that cannot, cannot.
Which statement best describes what makes Next-Generation Trust Security network-native rather than a conventional certificate lifecycle management tool?
A firewall continues to forward and inspect traffic normally, but it has disappeared from Strata Cloud Manager and cloud-delivered lookups have stopped. Which trust relationship should be investigated first?
An organization is preparing for the industry move toward a 47-day maximum certificate lifetime. Which statement is correct?