7 Steps to Offboard a Remote Developer in the UAE — the Exit That Cost Us Three Weeks of Cleanup

Three weeks after a senior backend engineer left a client of ours, a scheduled job failed. The job authenticated with a deploy key he had generated in his second month. His user account had been disabled on his last day, his laptop had been collected, and every box on the HR checklist had been ticked. None of that touched the key, because nobody had ever written it down.

Why developer offboarding is a different problem

Standard offboarding checklists were designed for people whose access is granted to them. Engineers are different in one decisive way: they create access as a side effect of doing their job. A developer generates keys, issues tokens, registers applications, connects services and signs up for vendors, often legitimately and often without any of it appearing in a system anyone administers.

So disabling the person’s login removes the access you granted and leaves the access they created. In a remote team the gap is wider still, because there is no physical moment of departure to anchor the process — no badge handed back, no desk cleared — and because the engineer may hold accounts registered from a personal device in a different timezone.

What follows is the seven-step process we run with UAE clients. It is deliberately boring, and it is written to be executed by someone who is not a security specialist.

Step 1 — Start the clock at notice, not at the last day

The hour a resignation is accepted, three things should happen: the offboarding checklist is created for this specific person, a handover owner is named on the remaining team, and a calendar is drawn with the access inventory in the first two days and revocation on the final day.

This matters because the notice period is the only window in which the engineer is simultaneously available, still paid, and still invested in leaving cleanly. Most engineers want a good exit; goodwill decays fast once they have started somewhere else, and a question sent to a personal email six weeks later has no reason to be answered.

Name the handover owner explicitly, by which I mean one person, not the team. Handovers addressed to a group are absorbed by nobody, and the resulting gap surfaces at the worst possible moment, usually during an incident.

Step 2 — Inventory access before revoking anything

Build the list first. Revoking without an inventory is how teams take down their own production systems on a Friday afternoon, and it guarantees that whatever you miss stays missed.

Walk five layers, in this order:

• Identity — the identity provider, email, and everything federated through single sign-on.
• Code and build — repository accounts, organisation membership, deploy keys, personal access tokens, CI/CD credentials, package registry publishing rights.
• Infrastructure — cloud console users, IAM roles, access keys, SSH keys on servers, VPN certificates, database users, bastion access.
• Third parties — payment processors, app store accounts, monitoring and error tracking, domain registrars, email delivery, and any vendor whose account was opened with a work or personal address.
• Data — shared drives, exported reports, local copies of production data, and anything synced to a personal device.

Ask the engineer to build this list with you rather than about them. Framed as “help us not break anything after you leave”, it is a collaborative twenty minutes. Framed as an audit, it becomes defensive and incomplete.

Step 3 — Separate the administrative tracks

Technical access and employment administration run on different clocks, and conflating them causes both to be done badly. The employment side depends heavily on the arrangement you are operating under, and it is genuinely different across mainland companies, free zone entities, DIFC and ADGM employment regimes, and contractor engagements handled through an employer of record.

The practical instruction is short: treat payroll, end-of-service entitlements and visa formalities as a separate track owned by whoever handles your employment compliance, and confirm the specifics with counsel or your EOR rather than with a checklist you found online. Our notes on employer of record and payroll mechanics in the UAE cover how that track is normally structured.

What you should not do is let the administrative track set the technical timeline. Access revocation happens on the last working day regardless of where the paperwork stands, and the paperwork should never be a reason to leave credentials live.

Step 4 — Take custody of anything registered to a person

This is the step that generates the ugliest surprises, and it must happen while the engineer is still cooperating.

Work through every account where the registered owner is an individual rather than the company: domain registrars, DNS providers, app store developer accounts, cloud billing owners, payment processors, error tracking, analytics, SMS and email delivery vendors, and any API service someone signed up for during a prototype that quietly became production.

For each one, either transfer ownership to a company-controlled identity or document precisely why you cannot. A surprising number of vendors make ownership transfer awkward, and discovering that while you still have a cooperative colleague is a very different experience from discovering it afterwards through a support queue.

The same logic applies to intellectual property terms in developer contracts: the moment to confirm who owns what is before the relationship ends, not during a dispute about it.

Step 5 — Run knowledge transfer against single points of failure

Most handovers fail because they are organised around what the engineer worked on. Organise around what only this engineer can do instead, which is a much shorter and much more useful list.

Ask four questions and write the answers down:

• What breaks that only you know how to fix?
• What do you do that is not written down anywhere?
• Which system would you be nervous about handing to someone else?
• What were you about to start, and what do you know about it that we do not?

Rank the answers by blast radius, then convert the top items into runbooks. The non-negotiable detail: the runbook is executed by the person inheriting it, while its author watches. A document that has never been run by anyone other than its author is a draft, and the gaps in it are exactly the tacit knowledge you are trying to capture.

Two to four sessions across the notice period is usually sufficient. The pattern generalises — it is the same discipline we describe for handing over a platform build when a vendor engagement ends.

Step 6 — Revoke in the correct order

Order matters, and getting it wrong leaves access behind a door you believe is locked.

• First, identity. Disable the identity provider account and terminate active sessions. This removes everything federated in one action.
• Second, long-lived credentials. Work the inventory from step two: deploy keys, personal access tokens, cloud access keys, SSH keys on hosts, database users, VPN certificates. These are independent of the account and must be removed individually.
• Third, shared secrets. Rotate anything the engineer knew that is still in use — shared admin passwords, service account credentials, signing keys. Knowledge of a secret is access to it.
• Fourth, physical and residual. Devices, hardware tokens, and any local copies of company data on personal equipment, confirmed in writing.

Do this as one scheduled block on the last working day, with the inventory open in front of you and someone ticking items off. Spread across a week, it is never finished.

Step 7 — Verify a week later, then decide what to hire

Seven days after departure, re-run the access inventory from step two and compare it against what you believed you revoked. This takes under an hour and it is the single highest-value hour in the entire process, because it is the only step that measures the outcome rather than the intention.

Expect to find something. Every team does: a monitoring integration still authenticating, a registry publishing right that was never tied to the identity provider, a vendor account whose ownership transfer silently failed. Finding these a week later is a maintenance task. Finding them a year later, during an audit or after an incident, is a different conversation entirely.

Then close the loop on hiring. A departure is the most honest information you will get about a role all year, because the work has just been enumerated in writing. Before reposting the old job description, read the runbooks the departing engineer produced and write the requisition from those. Our notes on benchmarking developer salaries in Dubai are the natural next step once you know what you are actually replacing.

What the whole thing costs

Roughly a day of the departing engineer’s time spread across the notice period, two to four hours from the handover owner, and one hour of verification a week after departure. The inventory template is reusable for every subsequent departure, which is the real return: the second offboarding costs a fraction of the first.

Set against that, the cleanup we opened this article with ran to three weeks of engineering time, most of it spent working out which of forty-odd credentials were still in use before anything could be safely removed. The process is not expensive. Skipping it is.

The pattern travels: our Singapore team runs the same seven steps with different employment mechanics on top, and our US practice finds the same split between granted and created access in every environment it reviews. The technical half of offboarding is jurisdiction-independent; only the paperwork changes.

Frequently asked questions