What is a zero-trust handover?

It's applying zero-trust security (never trust, always verify, least privilege) to the end of a project. The system runs in accounts you own, every credential is in your vault, the vendor's access was minimal and named throughout, and at handover it's rotated and revoked, with audit logs that let you confirm the vendor can no longer get in.

What should I get when a development agency hands over a project?

The running system in accounts you own, documentation and runbooks a new hire can follow, every secret in your own vault, and evidence that the vendor's access has been revoked. Not a zip file, a verbal walkthrough, and a phone number to call when it breaks.

How do I know a vendor no longer has access to my systems?

Only if it was set up so you can check. That means least-privilege named accounts from the start (no shared admin logins), a credential rotation and access revocation at handover, and audit logs you can read. If the vendor used a shared account or embedded keys in the code, you genuinely cannot know, and that's the problem a zero-trust handover prevents.

What's the difference between a handover and a clean handover?

A handover transfers the deliverable. A clean, zero-trust handover transfers ownership and removes the vendor's access verifiably: you hold the accounts and secrets, nothing depends on tribal knowledge, and there's no engineered dependency that quietly requires the vendor forever.

The Zero-Trust Handover: How to Own What a Vendor Built

Q: How do you offboard a software vendor securely?

Rotate every credential the vendor could have seen, revoke all their access (named accounts, not shared logins), and confirm it from audit logs. Make sure the cloud account, domain registrar, repositories, and app-store listings are owned by you, not by them. Then verify the system still runs without them. If access was shared or standing, you can't be sure, which is why it has to be designed in from day one.

Here’s a question that will tell you more about a technology partner than any reference call:

“When this is done and we part ways, can you prove you no longer have access to anything?”

Watch what happens. A good partner has already designed for that answer. A bad one realises, out loud, that they still hold a shared admin login, a personal API key buried in the config, the domain in their own registrar account, and the only copy of how the thing actually works.

Most handovers fail this test. This guide is about the kind that passes: a zero-trust handover, where you end up owning what was built and can verify the vendor kept nothing. It’s the technical, testable version of the promise every agency makes and few keep, handover, not dependency.

The two ways a handover goes wrong

The dependency leash. The system works, but only the people who built it understand it. Documentation is thin. The architecture lives in one person’s head. Every change is a new engagement. You can’t hire your own team to run it because nobody outside their building knows how. This is the gap we call the implementation chasm, and a vague handover is where projects fall back into it.

The security debt. This one is quieter and worse. The vendor finishes, you stop paying them, and they still have the keys: a shared admin account nobody rotated, an SSH key still on the server, their personal email on the domain registrar, an API token hard-coded in a config file. You didn’t keep them on; you just never got them out. Months later, that standing access is an audit finding, or a breach, that traces back to a vendor you forgot you’d trusted.

A good handover has to close both. Ownership and access.

What a zero-trust handover is

Zero trust is a security model: never assume trust based on where something sits or who set it up; verify every access, grant the least privilege necessary, and assume any credential could be compromised. It’s defined in NIST SP 800-207 and operationalised in the CISA Zero Trust Maturity Model.

Apply that lens to the end of an engagement and the handover stops being a ceremony and becomes a verifiable state change: the vendor goes from least-privilege, named, audited access to no access, and you can prove it. The system keeps running because it was built to be owned by you, not operated by them.

The zero-trust handover checklist

Score a partner, or your last project, against this.

1. You own the accounts, from day one. The cloud account, domain registrar, repositories, and app-store listings are in your name, with the vendor invited in, not the reverse. Ownership transferred “at the end” is ownership you don’t actually have until then, and sometimes never get.

2. Access was least-privilege and named. No shared admin@ logins. Every person and service had their own identity with only the permissions they needed. That’s what makes revocation possible and auditable later, you can’t remove access you can’t see.

3. Secrets live in your vault, not in the code. API keys, passwords, and tokens belong in a secrets manager you control, injected at runtime, never committed to a repo or pasted into a config. If a secret was ever in the code, it’s compromised the moment the repo changes hands, and must be rotated.

4. Handover rotates and revokes. On exit, every credential the vendor could have seen is rotated, and all their accounts and keys are removed. Not “we’ll leave it, it’s fine.” Rotate it, because the only safe assumption is that anything they touched, they still have.

5. You can verify it. Audit logs (who accessed what, when) let you confirm the vendor is actually gone, not just promised to be. Verification is the whole point of zero trust; a handover you have to take on faith isn’t one.

6. There’s no tribal knowledge left. Documentation and runbooks let a new hire operate, modify, and fix the system without a phone call. The knowledge is in your building, not theirs. This is the same bar as any production-ready system: team-owned, documented, monitored.

The exit test: rotate every credential, remove every vendor account, and confirm two things, the system still runs, and the vendor can’t get back in. A partner who built it right will tell you to go ahead and do exactly that.

Why this is a buying decision, not an IT detail

For a mid-market buyer, this is where lock-in and security risk actually live. The agency that keeps your domain, your admin login, and the only knowledge of your system isn’t more committed to you, it’s harder to leave, and quietly part of your attack surface. A partner who hands over cleanly is telling you they’re confident enough in the relationship that they don’t need to engineer your dependence.

That’s exactly the second signal in how to choose an AI implementation partner: if we parted ways in twelve months, what would we be left with? The zero-trust handover is the technical, testable answer. And it’s the discipline operators insist on and consultants skip, the unglamorous question of who owns it, and who can still get in, after everyone goes home.

How we hand over

We build for your ownership from the first day, not the last: your cloud accounts, your repositories, your domains, secrets in your own manager, and access that’s least-privilege and named throughout. At handover we rotate, revoke, and hand you the audit trail to verify it. Then we’re a call away if you want us, because you chose to, not because you’re stuck.

If you’re about to engage a partner, or trying to safely exit one, that’s worth getting right before anything is built. Tell us what you’re handing over (or taking back), and we’ll map the clean way out.