By Craig Davies, Chief Information Security Officer, Gathid.getty​We used to believe a breach was something that happened to a company. Today, it’s just as likely to happen through a company. The attack surface is no longer made of servers, endpoints and users we can see. It now includes every SaaS vendor, offshore contractor, managed service, marketing platform, billing partner, AI engine and integration layer that touches our data. The enterprise no longer owns its own identity perimeter. It rents it.​Given this reality, we're long overdue for a new concept in cybersecurity: the identity chain of custody.​In physical forensics, the chain of custody is the standard that ensures evidence remains intact, traceable and provable from collection to courtroom. In the digital world, we have nothing equivalent for identity. Once access leaves our directory, governance tends to dissolve into a vague mix of trust, contract clauses and assumptions. We behave as if security is transferable—as if outsourcing a function also outsources the accountability that comes with it. It doesn’t.​Today’s breaches often aren’t caused by internal misconfigurations or stolen credentials alone. They can begin in someone else’s infrastructure, feature someone else’s employee or act on someone else’s platform, using access we granted.​We can’t keep treating external access as a procurement decision. It's now a security architecture decision.​The Breach Is No Longer 'Yours,' Until It Is​As most CISOs already know, the attacker doesn’t care whether the vulnerability is technically “in your system” or in a third-party platform holding your customer data. To customers, regulators, journalists and class-action lawyers, the distinction doesn't exist.​In many breaches, the third party didn’t just have the data. They had access as the business. They weren’t an outsider in practical terms; they were a parallel identity layer trusted with the same privileges as the business itself.​ That's shadow access.​We outsource tasks and platforms because we assume a SaaS provider can do them better, faster and more cheaply than we can. And most of the time, they can. But when they get it wrong, the consequences are spectacular because they're amplified across every customer depending on them. A breach against a billing platform is never just one company’s problem. It's every company inside their system. That shared-risk model is invisible right up until the day it becomes headline-visible.​The Identity Problem No One Is Owning​Most enterprises still treat third-party access as a contractual obligation, not a system of live credentials and privileges. We're extremely diligent before onboarding a vendor. We carry out due diligence reports, obtain SOC 2 letters and request that cybersecurity questionnaires are completed. But then, companies are often startlingly passive once the integration is live. The security concern goes from “Should we trust them?” to “We trusted them, now let’s hope they stay worthy of it.​"What we lack is provenance of access: the ability to track, in real time, who's acting with our authority, inside environments we don’t control, through accounts we didn’t provision, using privileges we may not even know exist.​When Does Outsourcing Become A Breach?​When we move our data into a system we can't govern, is that moment itself already a breach of stewardship? My belief is that once our identity leaves our boundary, three things become true:• We stop being able to enforce context.• We stop being able to revoke access with certainty.• We stop being able to prove who touched what​.From a legal standpoint, the liability doesn’t dissolve. It expands. If a platform fails, your company is still the entity of record. Your name is on the notification letter. Your customers lose trust in you, not the supplier they’ve never heard of.​Identity Provenance: The Framework We're Missing​If we can track cryptocurrency across wallets, food through global logistics chains and digital evidence across court systems, we should be able to track access through supply ecosystems the same way. An identity provenance model would let us answer:• Who accessed enterprise data (internal, contractor, bot or platform)?• Under what authority and on whose behalf was it accessed?• Was the access time-bound, scoped and monitored?• Could we revoke that access in seconds, not weeks?• Can we prove ownership, usage and deprovisioning after the fact?​The fact that most companies can’t answer those questions today isn’t a failure of IAM tooling. It’s a failure of identity as an architectural discipline. We need the equivalent of supply-chain traceability for identity.​Preventing The Multi-Tenant Breach​The modern breach is no longer a single-victim event. It's a cascading failure, where one compromised system exposes 50 companies at once because every one of them trusted the same software layer.​​The only sustainable defense is to reduce persistent trust. The access granted to a third party on day one is rarely the access that worries a security team most. The real concern is what remains months later: the integration that expanded beyond its original purpose, the project account no one owns anymore, the vendor connection that still works even though the business relationship has changed. Access should be granted for a defined purpose and period and under conditions that can be independently verified. If a provider doesn't need enduring access to perform the work, they shouldn't have it.The same discipline needs to apply to non-human access. API tokens, service accounts and integrations are often treated as background infrastructure, but they can carry significant authority. Before a token is issued or a platform is connected, the organization should be able to answer basic questions: • What system is acting? • On whose behalf? • What data can it reach? • What authority will it inherit? Digital-twin models can help by showing how a proposed connection changes the broader authority structure before that access becomes part of the environment.Revocation is the clearest test of whether third-party access is truly under control. If removing a vendor still depends on someone finding the right ticket, emailing the right contact or trusting that another team has already handled it, the organization doesn't have a reliable control. During a breach, those delays matter. Trust should be granted narrowly, proven continuously and withdrawn cleanly. Otherwise, the organization is carrying residual trust and hoping nothing goes wrong.The Next Phase Of Security Leadership​Security shouldn't be something we wrap around a product or a platform. We should extend it around every identity acting in our name.​​We may outsource the work and the platform, but we can't outsource the responsibility. The chain of custody for identity must remain unbroken, even when the systems aren't ours.​​Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?