In the summer of 2023, an attacker read roughly 60,000 emails from the US State Department. They phished no diplomat and exploited no server in Foggy Bottom. They acquired one token-signing key from Microsoft's environment and minted their own tokens, which Exchange Online accepted - the signature checked out. Mailboxes at 22 organizations, State and Commerce among them, were read for weeks. The Cyber Safety Review Board called it preventable. The detail that should bother you most is simpler: one key was enough. Nobody logged in. The attacker simply signed.
The key that signs your workforce's access is a skeleton key to your company - and today it lives, whole and intact, inside somebody else's building. This post is about how NewCore makes that skeleton key stop existing. We call it Secure Split Key (SSK).
A short history of stolen god mode
My colleague Dima recently wrote about how identity became the attack surface; I won't rewrite it here - go read it. What I want to add is the pattern underneath the decade's worst incidents: the token-signing authority itself.
In 2017, CyberArk named the move Golden SAML: steal the signing certificate, forge assertions as any user - no password, no MFA prompt. By 2020 it was operational: during SolarWinds, Russia's SVR stole ADFS signing certificates and minted SAML assertions straight into Microsoft 365 - silently, because forged assertions never touch the identity provider's logs. The platforms themselves took hits too: Okta twice, via a support subprocessor in 2022 and its support system in 2023, turning stolen session tokens into live hijacks at 1Password, BeyondTrust, and Cloudflare.
Different vendors, different entry points, one shape: nobody defeats the authentication engine. One angle into the vendor - a subprocessor, a support tool, a crash dump - and the world's trust in that vendor's signature does the rest.
The identity supply chain is the shortest path to everything - which is why it is the one being attacked. Sources: Verizon DBIR 2025, IBM Cost of a Data Breach 2025.
This is not a story about careless vendors. It is about a hypothesis so old we stopped noticing it: the identity vendor must hold unilateral custody of the key that signs your users' access. Everything above follows mechanically from that assumption. "If the IdP is compromised, the entire org is compromised" - we have repeated it for twenty years as if it were physics. It is a design choice - and design choices can be challenged.
The stakes only compound: as I argued in my last post, agents will soon outnumber human identities by orders of magnitude - all vouched for by the same one key. So ask your identity vendor, verbatim: "If your platform were fully breached tomorrow, what could the attacker do to us?" The legacy model has one honest answer: everything. We built NewCore to give a different one.
One signature, two organizations
Here's the idea, minus the mathematics - there is real threshold cryptography underneath, the math checks out, and we will gladly share the details on request - but you don't need an equation to evaluate the property. The principle is dual control - two parties, neither sufficient alone - applied to the key that signs your workforce's access. Picture it as the ultimate seal of approval, a signature: John Hancock's. NewCore holds the ability to write John while your organization holds the ability to write Hancock. Neither half means anything alone - no application on earth accepts half a signature. Only when both halves land on the same assertion does a valid signature exist, indistinguishable from one produced the ordinary way.
One signature, two authors - same protocol, same apps, same login. Only the key has been pulled apart in space.
In protocol terms: an employee opens Salesforce and is redirected to NewCore, as with any identity provider. We authenticate against your policy, sign with our share, and hand back a partially signed assertion - invalid everywhere, for everyone. Your organization then applies its share and completes the signature inside your own perimeter. Where that co-signing runs is a deployment choice - in the browser, at your network edge, or anchored to the device - different tradeoffs, same property: completion happens on your side of the wall, never on ours. What leaves is a completely standard SAML response, verified against the ordinary public key in your metadata.
Two properties carry the weight. The full private key exists nowhere - not at NewCore, not on the endpoint, not at the moment of signing. Generation supports several ceremony models, including distributed key generation, where a complete key never exists even for an instant. And your share never touches NewCore's servers - we do not store it, see it, or hold anything that could recover it. Lose it and the fix is a fresh ceremony and a certificate rotation, the same motion as any key rollover. What we cannot do is hand the old share back - which is exactly the proof the guarantee is real.
Two organizations, not two vaults
Splitting keys is not new. HSMs shard them, vendors run dual-control ceremonies, some platforms keep a key per tenant. None of it changes the property that matters: every shard still lives under one organization's roof - one directory, one admin population phishable in one campaign, one EDR stack, one set of subprocessors. Controls fail in correlated ways inside a single company; the Okta support breach began with one credential saved in the wrong place.
Put the two halves in two different organizations and the attacker's job changes in kind, not degree. Two admin teams, two endpoint stacks, two monitoring pipelines, no shared accounts - operated by people who have never met. A breach of one yields no purchase on the other; "go deeper" becomes "run two unrelated, simultaneous campaigns and win both before either notices." Banks have sold this control for a century: the deposit box opens only when the guard key and yours turn together. Rob the bank - your box stays shut.
Two keys, two organizations - one bolt.
Zero Blast Radius
Steal our database, backups included: you hold a mathematically useless fragment. Achieve full code execution on our signing service: you can emit partial signatures all day; no application will accept one. So here is the strongest sentence in this post: if NewCore is completely compromised - infrastructure, database, backups, admin consoles, all of it - the attacker cannot complete a single login, for a single user, to a single application. Not "reduced blast radius." Zero valid tokens.
Blast Radius, Scenario by Scenario
What the attacker actually gets
| The Attacker Achieves | Legacy Identity Platform | NewCore SSK |
|---|---|---|
| Steals the vendor's database, backups included | Holds the signing key. Forges valid tokens for every user, to every application. | Holds a mathematically useless fragment. Zero valid tokens. |
| Gains full code execution inside the vendor | Signs anything at will. God mode across the entire connected SaaS estate. | Can emit half-signatures no application accepts. Not one login completes. |
| Phishes an employee - password, username, OTP | Credentials are enough. Attacker signs in as that user from their own infrastructure. | No path to your co-signer from outside your perimeter. The assertion never completes. |
| Breaches the vendor AND your perimeter, at once | Compromised. (One breach was enough anyway.) | Compromised. The honest limit of a 2-of-2 split - and why the halves live in two separate, unrelated organizations. |
Scenarios drawn from the SSK threat model. Session hijacking after a login completes is a different battle - see the honest-limits section.
A matrix comparing attacker outcomes under a legacy platform versus SSK across four scenarios: vendor database stolen, full vendor code execution, employee phished, and both organizations breached at once.
What the attacker actually gets, scenario by scenario - including the honest limit of a 2-of-2 split.
Honesty about the edges: a 2-of-2 split means an attacker who compromises both organizations at once can sign. But read what that requires - your own perimeter, already breached. An attacker already inside your walls doesn't need to forge logins; they take over the sessions that exist. That is a different battle (one we fight with device-bound sessions), and nothing substitutes for guarding your admin console. What SSK removes is the decade's recurring scenario: access minted from outside, by breaching someone you trusted. As Dima put it, a vendor compromise should never be enough to compromise the customer. SSK is that principle, made of cryptography instead of promises.
Phishing stops paying out
Removing the single point of compromise had a side effect. Phishing works because credentials are bearer instruments: whoever presents them, from wherever, gets in. Under SSK, a phished password and a relayed one-time code buy exactly one thing: a partial token, invalid everywhere. Completing it requires your share, and your share answers only from inside your genuine corporate context - wherever your deployment anchors it. A phishing page runs on attacker infrastructure, an adversary-in-the-middle proxy terminates on the attacker's box - neither has a path to your co-signer, so the assertion never completes. Employees stay human - some will always click. With SSK, clicking stops being a company-ending event.
Phished credentials buy a partial token - and a dead end.
A frictionless experience. Nothing changes for your apps or your users.
The first question every security team asks: what changes across four hundred SaaS apps? Nothing. Each app receives a standard, spec-compliant SAML response and verifies it against the public certificate in metadata - no plugin, no SDK, no ticket to Salesforce. Setup is pointing the app at the SSK metadata URL, the same motion as any SAML integration. The login-time cost is one local signing operation: milliseconds, no extra round trips. Users see the login they saw yesterday. Admin lift: a one-time ceremony, an extension through your existing endpoint channel, a toggle on by default. Controls fail when they tax users or app owners until somebody routes around them. SSK charges neither.
Zero Trust was never supposed to stop at the identity provider
Zero Trust, in one sentence, is the removal of implicit trust. The industry spent a decade applying it to networks, devices, and users, and then left one system holding a standing grant of absolute trust - the identity platform. It's the one system that can impersonate anyone, to anything. "Assume breach" has to include the party doing the verifying. SSK applies Zero Trust to the vendor itself: every assertion your apps accept carries proof, by construction rather than policy, that your organization co-approved it. We didn't bolt Zero Trust onto the identity layer. We aimed it at ourselves.
Where this leaves us
For twenty years, buying an identity platform meant accepting a hypothesis: if the vendor falls, you fall. Vendors asked for trust and offered compensating controls - certifications, audits, ceremonies. All worthwhile; none of them architecture. The recent incidents are that bill arriving; the manifesto we published at NewCore's founding came from watching it happen.
The next decade of identity gets judged by one question - ask it of anyone who signs your workforce's access: "If your platform is fully compromised, what can the attacker do to us?" The legacy answer is everything. The modern answer: nothing - not one login, for one user, to one application. Secure Split Key is live for SAML as well as OIDC today - and deploys in days, not quarters. Want to watch a fully privileged attacker stare at a useless partial token? Request a demo. Bring your hardest questions - I intend to keep answering them in public.
Misha Seltzer is VP Technology & Strategy at NewCore. Previous: How EMA Enables the Rise of the Synthetic Employee.