2026-07-17 // Alexandru Cazan

Nobody Owns the Seam

Systems do not fail in the middle. They fail at the joins – and the joins have no owner, no budget and no alert.

Ask who owns the database and you get a name in four seconds. Ask who owns the firewall, the domain, the identity provider – all fine, all named.

Now ask who owns the space between them. The delegation. The trust. The handoff. The thing that was configured once, during a migration, by someone who has since left.

Silence. Every time, for twenty-five years.

Systems do not fail in the middle. They fail at the joins. And the joins have no owner, no budget, no dashboard and no alert.

The seam is always the youngest part and the least documented

The pattern predates the cloud by decades.

The nineties. A domain delegated to a nameserver at a company that got acquired. The delegation stayed. The nameserver stayed. Everything worked, so nobody looked – for years – until the day it did not, and then nobody could even say who was supposed to be answering.

The two-thousands. Every merger produced a permanent archaeological layer. Two mail systems joined by a connector nobody documented. Two directories joined by a trust relationship whose purpose was known to exactly one person. The connector is not owned by either side. It is owned by the merger, and the merger is over.

The twenty-tens. Vendors. The monitoring vendor has an account in your environment. The backup vendor has one too. The relationship ends, the invoice stops, the contract is filed – and the access stays. Nobody offboards an integration, because offboarding an integration is nobody’s job.

Now. Cross-account roles, federated identity, OIDC trusts, delegated subdomains, third-party SaaS with tokens into your data. The modern estate is mostly seams. We have industrialised the joins and left the ownership question exactly where it was in 1998.

What I found this year

An audit. A subdomain, delegated by name server records from the production DNS zone to a zone that lived in a different, older cloud account.

That second account was dead. Wound down. The zone inside it had been deleted.

So the production DNS was confidently pointing the world at a zone that no longer existed. It had been doing this for about five months.

This is not a cosmetic problem. A dangling delegation is a takeover primitive: the name still resolves through your authoritative servers, but the answer comes from an empty chair – and an empty chair can be claimed. Anyone who recreates that zone in that provider inherits your subdomain, under your brand, with your name in the certificate.

Nobody had done anything wrong. The production DNS team owned production DNS. The cloud team owned the cloud. The wind-down team owned the wind-down. All three did their jobs correctly. The delegation between them was owned by nobody, so it survived the death of the thing it pointed to.

Why seams outlive everything else

Three reasons, and they compound.

They are invisible when healthy. A working seam produces no output. You cannot audit a thing that only exists as an absence of trouble.

They are created under time pressure. Migrations, acquisitions, incidents. Nobody designs a seam in a calm room – it gets made at 2am to unblock something, and permanence is an accident.

Deletion is asymmetric. When you kill a system, you kill the system. Nobody walks the graph of everything that pointed at it. Decommissioning is a checklist about the thing, never about the things that trusted the thing.

How to find yours

You will not find seams by looking at systems. You find them by looking for references. Start here:

  • Every delegation. Walk your DNS and ask, for each one: does the target still exist, and can I name the person responsible for it? Any “I think so” is a finding.
  • Every trust. Federations, cross-account roles, OIDC providers, API integrations. For each: what is on the other end, is it still alive, and who offboards it when the contract ends?
  • Every credential you did not issue. Service accounts, vendor accounts, integration users. If you cannot say what created it and what would remove it, it is a seam.
  • Follow the dead. Every decommissioned system, dead account, ended vendor. Do not ask what it pointed at – ask what still points at it. That is where the risk lives.
  • Give every seam a name. Not a team. A person. An unowned join will always lose the argument for attention.

The rule

When you turn something off, the work is not turning it off. The work is finding everything that still believes it is on.

That belief can outlive the system by years – and it is patient, and it is quiet, and one day somebody who is not you decides to answer on its behalf.