How should organisations use pnPKI and SAML together in a modern identity strategy?

Why This Matters for Security Teams

Organisations rarely choose between SAML and pnPKI because one is “better” than the other. The real issue is assurance fit. SAML is well suited to federation, SSO, and day-to-day workforce access, while pnPKI adds stronger evidence quality for transactions that must stand up to audits, disputes, or legal review. That distinction matters because identity systems are often asked to do both convenience and proof, and one control rarely satisfies both.

Current guidance suggests treating these as complementary layers rather than competing standards. SAML assertions can move users through business apps quickly, but they are not designed to provide the same cryptographic signing strength, device-bound trust, or evidentiary properties as certificate-based signing. In identity-heavy environments, weak separation between convenience access and binding approvals becomes a governance gap, not just a technical preference. NHIMG research shows that Ultimate Guide to NHIs notes 97% of NHIs carry excessive privileges, which is a reminder that access decisions and proof requirements should not be collapsed into a single control path.

In practice, many security teams discover that signing assurance was overestimated only after a challenged transaction, audit request, or regulatory review has already exposed the gap.

How It Works in Practice

The cleanest operating model is to define SAML as the federation layer and pnPKI as the evidentiary layer. SAML handles authentication and session establishment across enterprise applications through the identity provider, while pnPKI signs the specific event, approval, or document that needs durable proof. In other words, users log in with one pattern, but not every business action receives the same assurance treatment.

This works best when policy distinguishes between access and commitment. For example, a workflow may allow SAML-based SSO for claim review, but require pnPKI signing for final settlement approval, procurement authorization, or regulated filing submission. That keeps the user experience efficient without weakening non-repudiation. The FATF Recommendations are useful here because they reflect the broader compliance expectation that higher-risk transactions need stronger identity evidence than routine access.

• Use SAML for authentication, session management, and broad federation.
• Use pnPKI for digitally signing high-impact actions, approvals, and records.
• Bind certificate issuance to verified identity proofing and lifecycle controls.
• Log both the SAML authentication event and the pnPKI signature event for auditability.
• Define revocation and expiry rules so certificates do not outlive employment, role, or authority.

That lifecycle discipline matters because weak key management can undermine otherwise strong assurance. NHIMG’s Top 10 NHI Issues research is a useful reminder that identity risk often accumulates where governance, rotation, and revocation lag behind operational reality.

These controls tend to break down when certificate issuance, signing authority, and account federation are managed by separate teams without a shared revocation process.

Common Variations and Edge Cases

Tighter certificate-based controls often increase operational overhead, so organisations must balance stronger assurance against user friction and support burden. That tradeoff is real, especially in environments with contractors, frequent role changes, or cross-border operations where certificate provisioning is slower than SSO enrolment.

There is no universal standard for this yet, but current guidance suggests using pnPKI selectively where legal enforceability or high-quality evidence is required, rather than trying to replace SAML everywhere. Some organisations also use SAML to bootstrap access to a certificate workflow, or to support conditional escalation where the user completes most steps with SSO and only signs the final commitment with pnPKI. That can work well, provided the control boundary is explicit.

Edge cases include shared service desks, delegated approvals, and hybrid human plus automation workflows. In those environments, the identity question is not simply “who authenticated,” but “who had authority to commit, and with what proof.” The strongest results usually come from aligning the assurance level to the transaction, not the application name. For background on how over-privilege and weak lifecycle control magnify identity risk, see 52 NHI Breaches Analysis and the broader Ultimate Guide to NHIs.

Best practice is evolving, but the practical rule remains simple: use SAML for reach, and pnPKI for proof.

Related resources from NHI Mgmt Group

• Should organisations use SAML and OAuth together?
• Should organisations use NFC verification instead of OCR document checks?
• Why do non-human identities create audit risk in modern environments?
• When does a machine identity become a compliance problem?