By NHI Mgmt Group Editorial TeamBased on Newcore: “Secure Split Key: No Single Key, No Single Point of Compromise for IdP” (August 11, 2026)

TL;DR: A single token-signing key can turn an identity vendor compromise into enterprise-wide account takeover, according to Newcore, citing incidents such as the 2023 Microsoft token-signing key theft and Golden SAML. The core issue is that identity platforms still concentrate unilateral signing authority in one place, creating a trust assumption that Zero Trust never removed.


At a glance

What this is: This is an analysis of how split-key signing changes the trust model for identity vendors, with the key finding that unilateral signing authority is the structural weakness behind vendor-to-customer compromise paths.

Why it matters: IAM and NHI teams need to understand that identity provider compromise can become a signing problem, not just a login problem, which changes how blast radius, trust boundaries, and vendor risk are assessed.


Context

Identity vendor trust depends on who can sign assertions, not just who can authenticate users. When one party holds the full signing key, compromise of that party can produce valid tokens that downstream applications will accept without a normal login event.

This article is about the governance flaw in that model: a single signing authority creates a customer-wide failure domain inside the vendor's environment. Split-key signing changes where trust is anchored, but it also changes how practitioners should think about vendor breach resilience and authentication sovereignty.


Key questions

Q: What breaks when an identity vendor is compromised?

A: When an identity vendor is compromised, the break is often not limited to the vendor environment. Customer authentication workflows, support trust, deployment knowledge, and privileged access paths can all become part of the attacker’s reach. The practical failure is correlated exposure across many organisations that assumed the vendor was outside their own risk perimeter.

Q: Why do signing-key compromises create such large blast radius?

A: Because relying applications usually trust the signature, not the path the signer took to create it. If the signer is compromised, the attacker can issue valid access that looks indistinguishable from legitimate authentication. The blast radius is large because the trust point sits upstream of every application that accepts that issuer.

Q: What are the signs that identity trust material is too concentrated?

A: Warning signs include one organisation controlling all signing authority, recovery paths that can recreate tokens without secondary approval, and vendor support processes that can influence authentication outcomes. If a single compromise can affect multiple SaaS applications, the trust model is concentrated enough to warrant redesign.

Q: How should teams evaluate split-key signing versus traditional federation?

A: Use split-key signing when the business requirement is to keep standard federation while removing unilateral issuer custody. Traditional federation centralises trust in the identity provider, while split signing distributes the act of authorisation itself. The decision is about whether you can tolerate a single organisation being able to impersonate your users.


Technical breakdown

Why token-signing keys create a hidden trust boundary

In federated identity, the signing key is the root of downstream trust. If an identity provider signs a SAML or OIDC assertion, relying applications generally accept it because the signature proves the issuer controlled the key. That makes the key more powerful than a password, MFA factor, or session token. A stolen signing key can mint new assertions for any subject the issuer would normally recognise, which is why attacks against signing material bypass the usual login event entirely. The critical architecture question is not whether authentication happened, but who had the ability to assert it.

Practical implication: Treat signing-key custody as a high-risk trust boundary, not a routine identity control.

How split-key signing changes the authentication model

Split-key signing uses threshold cryptography or dual control so that no single party can complete a signature alone. One share held by the vendor and one share held by the customer must both participate before a valid assertion exists. That preserves standard protocol compatibility while removing unilateral signing authority from either side. The important architectural change is that compromise of one environment no longer yields a complete token-signing capability. This is a structural control, not a policy promise, because the private key never exists in one place in usable form.

Practical implication: Use split signing where downstream applications must trust identity assertions but the vendor cannot be allowed unilateral signing power.

Why traditional vendor controls do not solve the signing problem

Certifications, audits, and standard hardening reduce risk, but they do not change the core trust model when one organisation can sign for another. If the vendor's environment, support tooling, or subprocessor path is compromised, the attacker may still obtain enough material to mint valid assertions or hijack existing trust. That is why incidents involving signing keys and support-system compromise have such large blast radius. The failure is architectural: a customer is depending on another party's security posture to protect a credential that can impersonate its workforce across applications.

Practical implication: Assume audits are compensating controls, then decide whether the architecture itself needs to remove unilateral signing authority.


Threat narrative

Attacker objective: To impersonate users or administrators at scale by minting valid identity assertions that downstream services trust.

  1. Entry begins with compromise of the identity vendor's environment, support path, or signing material rather than a direct attack on the customer.
  2. Credential access occurs when the attacker obtains a token-signing key or equivalent trust material that the relying applications accept.
  3. Escalation follows when forged assertions or tokens are minted with valid signatures, allowing impersonation at scale across connected services.
  4. Impact is enterprise-wide account takeover, token forgery, or silent mailbox and application access without a conventional login event.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Unilateral signing authority is the real identity trust defect. The problem is not simply that vendors can be breached, but that a single vendor-held key can make the breach authoritative everywhere downstream. That design creates a customer-wide trust dependency that traditional perimeter thinking never removed. The practitioner conclusion is to measure identity risk by who can sign, not just who can authenticate.

Split-key signing is an architectural response to assumption collapse. The old assumption was that the identity provider may legitimately hold the full power to issue accepted access for the customer. That assumption fails when one compromise can mint valid access without touching the customer's own controls. The implication is that identity governance must separate issuance power from unilateral custody, not merely strengthen the vendor's environment.

Identity vendor compromise should be evaluated as a supply-chain event. When the issuer of trust is external, the relying organisation inherits the issuer's failure domain whether it wants to or not. This aligns more closely with supply-chain risk than with ordinary account compromise, because the attack propagates through accepted trust rather than stolen user credentials. Practitioners should re-evaluate vendor assurance around signing authority, support access, and recovery ceremonies.

Zero Trust is incomplete if the identity issuer remains a standing root of trust. The model says to assume breach, but many identity architectures still preserve one entity that can vouch for everything. That makes the trust hierarchy internally inconsistent. The practitioner conclusion is that Zero Trust for identity has to include the party that signs the assertion, not only the systems that consume it.

Zero standing privilege has a natural analogue in identity signing. If no one should hold persistent elevation, then no vendor should retain unconditional, reusable authority to sign every customer assertion alone. That does not remove authentication trust, but it does reduce the blast radius of issuer compromise. Practitioners should treat signing authority as an elevated privilege domain, not a background plumbing function.

From our research library:

  • The average worker in a typical enterprise holds 96,000 entitlements, and 38% of IdP accounts are dormant, according to Veza's 2026 State of Identity and Access Report.

What this signals

Identity governance now has to account for issuer compromise, not just user compromise. Federation concentrates trust upstream, so a vendor signing key becomes part of the customer's effective control plane. That means access governance reviews need to include who can mint assertions, who can recover signing material, and how much trust a downstream app places in a single issuer.

Split-key designs shift assurance from promises to structure. If one party cannot complete a signature alone, then the usual vendor breach scenario no longer maps cleanly to mass token forgery. For programme owners, that changes the question from whether the vendor is compliant to whether the architecture still permits unilateral trust completion.

Identity provider compromise should be measured as a blast-radius problem. The practical test is simple: if the issuer disappears or is breached, how many applications can still be impersonated with accepted signatures? That question belongs in vendor risk reviews, federation design reviews, and recovery planning alike.


For practitioners

  • Review signing authority custody Map which party can complete identity assertions today, where the private key or equivalent trust material lives, and whether any single compromise can mint valid access across all relying apps.
  • Separate issuance from unilateral control Require architectures that prevent one organisation from independently producing accepted assertions for your workforce, especially where the identity vendor also operates support and recovery tooling.
  • Reassess vendor breach blast radius Test vendor compromise scenarios against your actual federated apps, including mailbox access, SaaS admin paths, and recovery workflows that may trust the issuer without secondary verification.
  • Harden support and recovery paths Treat support systems, incident-response channels, and admin recovery steps as part of the identity trust chain, because those paths often become the shortest route to signing material.
  • Demand evidence of split-key operations Ask vendors to show how co-signing, key ceremonies, revocation, and rotation work when one party cannot complete a signature alone, and how failure is handled if one share is unavailable.

Key takeaways

  • A single signing key can turn an identity platform compromise into organisation-wide impersonation, which is why issuer custody is the central trust problem.
  • The evidence in recent identity incidents shows that downstream applications often trust signatures more than they trust the surrounding environment, so the blast radius follows the key.
  • Practitioners should reduce unilateral signing authority, test vendor compromise scenarios against real applications, and treat identity issuance as a governed trust boundary.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-02 — Secret LeakageA stolen signing key is the core trust material exposed in this article.
NHI-05 — Overprivileged NHIA single key that can sign for every user is an overprivileged trust primitive.
NHI-07 — Long-Lived SecretsThe article centres on standing signing authority that persists across sessions and incidents.
Recommendation — Protect signing keys as high-value secrets and eliminate paths that expose them to compromise. Reduce any NHI or issuer that can independently authorise broad access without second-party control. Shorten the lifetime and custody window of signing material wherever architecture allows.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsFederated assertions are the authorisation layer that downstream apps consume.
Recommendation — Review authorization boundaries so no single issuer can silently grant enterprise-wide access.
MITRE ATT&CKTA0006;TA0010 — Credential Access; ExfiltrationThe article's incidents rely on obtaining signing material and using it to access mail and apps.
Recommendation — Map signing-key theft scenarios to credential-access and exfiltration detection coverage.

Key terms

  • Token Signing Key: A token signing key is the cryptographic secret used to create and verify authentication tokens. If it is compromised or abused, attackers may mint tokens that a service accepts as valid, which can undermine login trust across multiple accounts and sessions.
  • Split-key signing: A threshold cryptography model in which no single party holds the complete private key. Each participant contributes a partial signature, and a valid token is produced only when all required shares cooperate, reducing the blast radius of unilateral compromise.
  • Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
  • Federated assertion: A federated assertion is the signed message an identity provider sends to a service to prove a user or workload should be accepted. Because relying services treat the signature as proof, the security of the assertion depends heavily on who controls the signing authority.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 14, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org