A Departing Dubai Developer Kept Production Access for 41 Days: the 7 Step Offboarding I Run Now

We found it during an unrelated review. A backend developer had left a Dubai client in February, worked their notice properly, handed over cleanly, and been thanked in a team meeting. Their personal access token was still authenticating against the production deployment pipeline 41 days later. Nobody had done anything wrong. The account had been disabled on the last working day exactly as the checklist said. The token simply was not attached to the account.

That is the shape of almost every offboarding failure I see in this market. Not negligence, not malice: a checklist that was written for an employee and applied to an engineer. What follows is the sequence I use now. It takes about four to six hours of real effort spread over the notice period, plus one short pass a week after the person has gone.

Why engineering offboarding fails differently

A standard HR offboarding assumes access is granted by an administrator and therefore removable by an administrator. Engineering breaks that assumption in three ways, and all three are normal rather than deviant.

Developers create their own credentials. Personal access tokens, SSH keys, API keys, service-account impersonations and CI secrets are all things a competent engineer makes in the course of doing the job well. None of them necessarily appear in your identity provider, and disabling the human account does not always invalidate them.

Developers accumulate access that nobody re-reads. The permission added for a 2024 migration stays. The production read granted during an incident stays. By year three, the honest answer to the question of what a senior engineer can reach is that nobody knows without looking.

And in a smaller Dubai team, developers share accounts, because the alternative was paying per seat on a tool the team needed in a hurry. Those shared credentials are the ones that quietly do not get rotated, because something undocumented depends on them and rotating feels riskier than leaving it.

Step 1: Trigger the checklist from one recorded event

Write down the single event that starts the clock, and make it something with a timestamp. In practice that is written notice received, logged by whoever received it, on the day it arrived.

This sounds procedural and it is the highest-leverage item on the list. The common failure is that offboarding begins with a conversation, and conversations do not have start dates. The developer tells their manager on a Tuesday. The manager waits to tell anyone until the replacement plan is clearer. Three weeks later IT learns about the departure from a calendar invitation for a farewell lunch, and now there are nine days to do a thirty-day process.

Assign one owner who is not the departing developer’s line manager, for the reason that the line manager has three competing jobs in this moment: protect delivery, start hiring, and keep the relationship warm. Those are legitimate priorities and none of them is credential hygiene.

Step 2: Build the access register before anyone is told

Do this before the departure is announced internally. Not for secrecy, for accuracy: once a team knows someone is leaving, people start tidying, revoking and reassigning, and your inventory becomes a reconstruction rather than a snapshot.

Enumerate, with an owner and a revocation method for each line:

• Identity provider groups and anything federated through them.
• Source control: organisation membership, per-repository grants, and separately, every personal access token and SSH key registered to the account.
• Cloud: console users, roles assumed, long-lived keys, and service accounts the developer can impersonate.
• Pipelines and secrets: CI credentials, deployment keys, secret manager policies, and any runner configured on their machine.
• Data: production database users, read replicas, analytics warehouses, and exports sitting in personal cloud storage.
• Paging and alerting: on-call schedules, escalation policies, and the phone number attached to them.
• Third-party tools, including ones bought outside procurement on an individual card: error trackers, log platforms, AI coding assistants, design tools, package registries.
• Shared and service accounts whose password the developer knows, listed explicitly even when rotating looks inconvenient.
• Customer systems, if your engineers hold access to client environments, which in UAE agency and systems-integration work is common and is the highest-consequence line on the register.

Keep the register in one place with a status column. The register, not the checklist, is the artefact you will be glad to have in nine months.

Step 3: Split knowledge handover from access revocation

These two tracks pull in opposite directions, which is exactly why one checklist with one owner always compromises both. The handover needs the developer to retain enough access to be useful. The revocation needs their reach to shrink steadily. Run them in parallel, with two named owners and one person who confirms both are closed.

Line manager owns the handover and its acceptance test. Platform, IT or security owns the register and the revocation. If your organisation is too small for that split, give the revocation to someone outside the departing developer’s immediate team, even a founder. The separation is what matters, not the job title.

Step 4: Test the handover against the pager, not a document

A handover document proves someone wrote a document. The test I use instead: while the departing developer is still available but deliberately silent, the receiving engineer takes a real on-call shift covering that area, or resolves a real ticket in it unaided.

Run it with the departing developer reachable as a last resort and instructed not to volunteer anything. Every question the receiver has to ask is a gap in the handover, so write each one down. Those questions are the actual handover document, and they are far better than the one anyone would have written unprompted.

Schedule this at the notice-period midpoint rather than the final week, so there is time to fix what it exposes. If your team runs a structured runbook already, our knowledge transfer runbook covers the document side in more depth.

Step 5: Stage the revocation, least disruptive first

Order matters, because some revocations break things that other people depend on. Work through the register in four waves:

1. Silent and safe, immediately: remove standing production write access, customer environment access, and anything the handover does not require. Most developers do not notice and nothing breaks.
2. Self-created credentials, before the last day: revoke personal access tokens, SSH keys and personal API keys explicitly, one by one, from the register. Disabling the account is not a substitute and this is the wave that gets skipped.
3. Shared and service credentials, in a planned window: rotate anything the developer knew, in a scheduled maintenance slot with the team watching. In UAE teams running a Monday to Friday week with a Friday half day, put this early in the week, never on the last afternoon.
4. Primary identity, on the last working day: disable the account, remove from paging, transfer ownership of repositories and documents rather than deleting them.

If you genuinely need a post-departure question window, make it read-only, time-boxed in writing and automatically expiring. An open-ended "just in case" access grant is the thing you will find still live during an audit next year.

Step 6: Close the device, key and certificate loop

Recover and record, on or before the last working day: laptops and their chargers, phones and tablets, hardware security keys, VPN certificates and client certificates, building access cards, and any home office equipment the company bought.

Two UAE specifics change how this step runs. First, a large share of technical staff here are expatriate hires, and a meaningful number leave the country within days of their last working day. Device return that assumes a leisurely drop-off at reception the following week fails routinely. Collect hardware on the final day, not after it.

Second, remote and hybrid engineers in this region are frequently working from another emirate or outside the country entirely, which turns device return into a shipping problem with customs attached. Decide before the notice period ends whether the device is being shipped back, collected locally, or written off and remotely wiped, and write the decision down. If a machine is not coming back, make sure your management tooling can actually revoke its certificates and remove its access, and confirm it did rather than assuming.

Record what came back and what did not. A short written record of an unreturned laptop that was wiped and de-enrolled is worth considerably more than a vague recollection.

Step 7: Run a seven-day evidence pass and feed it back

Seven days after the last working day, do a 30-minute pass whose only purpose is to catch what the checklist missed:

• Authentication logs: any successful authentication by that identity, token or key since the last working day.
• Orphaned credentials: tokens, keys and service accounts with no current owner, which is where the departed developer’s leftovers live.
• Webhooks and integrations pointed at personal endpoints or accounts.
• Repository and document ownership still attached to the disabled account.
• Third-party seats still billing, which is the one that gets management attention.

Then do the part that compounds: write down every gap you found and fix it in onboarding instead of offboarding. Nearly everything this pass catches was created by a provisioning habit. Tokens that outlive accounts are an access-granting decision. Shared credentials are a procurement decision. If the same three gaps appear at two consecutive departures, the problem is your onboarding process, and no offboarding checklist will outrun it.

The three ways this process still goes wrong

The friendly departure. The easiest offboardings are the most dangerous, because when someone leaves on good terms the whole process feels like an accusation. Teams soften it, skip the register, and leave a read-only grant open indefinitely. The checklist exists precisely so that nobody has to decide how much they trust the person leaving.

The retained contractor. Someone leaves as an employee and stays on for a few hours a week, and the access question gets deferred because they are "still involved". Treat it as a full offboarding followed by a fresh, narrower provisioning under a separate identity. Any other handling means nobody knows which hat the access belongs to.

The emergency rehire of their access. Three weeks after departure, something breaks that only they understood, and someone re-enables the account at 11pm. If that happens, re-run step 5 and step 7 the next morning, and log it. The re-enablement is almost never undone on its own.

For the attrition pattern behind repeat departures, see our guide on engineering exit interviews. For verification practice on the way in, which is where several of these gaps are cheapest to prevent, see UAE developer background checks. And if a departure has left you short a capability rather than a person, product development services in the UAE covers the build options.

Frequently asked questions

When should access revocation actually happen for a developer leaving a Dubai team?

Tie it to the last working day, never to an administrative milestone outside engineering. In UAE teams the employment end date, final settlement and work permit cancellation are handled by HR and the public relations officer on their own timelines, and those routinely run past the day the person stops writing code. If IT waits for the paperwork, access stays live for weeks after the desk is empty. Run the reverse pattern: production and customer data access shrink progressively during the notice period, everything else is revoked on the last working day, and administrative closure happens afterwards against a register that is already empty. The one exception worth planning is a short read-only window for a named handover question, time-boxed in writing and automatically expiring.

What do most UAE employers miss in a developer offboarding?

Four things, in order of how often I find them. First, personal access tokens and SSH keys the developer created themselves, which appear in no identity provider and survive the account being disabled. Second, shared service accounts, common in smaller Dubai teams, whose passwords nobody wants to rotate because something undocumented depends on them. Third, third-party tools signed up outside procurement, from error trackers to AI coding assistants, each holding a slice of the codebase. Fourth, webhooks and integrations pointed at the departing person’s own endpoints. None of these are exotic. They are invisible to a process that only disables the primary account.

How long does a proper developer offboarding take, and who should own it?

Plan for the length of the notice period for the handover, roughly four to six hours of actual effort for access and devices, and one short pass a week after departure. Notice periods for UAE technical staff are commonly around 30 days and can run longer by contract, which is enough time if the process starts on day one rather than in the final week. On ownership, the mistake is giving the whole thing to the line manager, who is simultaneously protecting delivery, hiring a replacement and keeping a relationship warm. Split it: the line manager owns the knowledge handover and its acceptance test, someone in platform, IT or security owns the register and revocation, and one person confirms both are closed.

Does this change for a contractor or an outsourced developer rather than an employee?

The access and device steps matter more, and the timeline is usually shorter. A contractor or vendor engineer often has a shorter notice obligation, may be reassigned quickly by an agency, and frequently uses their own hardware, which removes device recovery and replaces it with a harder question about what company data sits on a machine you do not control. Three adjustments: agree before the engagement starts that code and credentials live only in systems you administer, give vendor engineers access through a separate identity group so revocation is one action rather than an audit, and make the handover artefact a contractual deliverable rather than a favour. If the engagement is ending because the work is coming in house, the step 4 pager test matters more than anything else here.

William

Talent Sourcing Expert at HireDeveloper.ae. Works with UAE employers on sourcing, screening and the joining and leaving processes either side of a technical hire, including the access questions most checklists leave out.