{
 "slug": "creator-binding-offboarding",
 "topic_id": "TOPIC-211",
 "cluster": "Machine, Agent & Signing Identity",
 "tier": "Tier A",
 "title": "The engineer left; the integration did not",
 "summary": "Offboarding disables a directory account and reclaims a laptop. It does not touch the personal access tokens, integration keys, webhooks and service accounts the departing engineer created, because nothing records that they created them.",
 "lede": "Research in 2026 put residual application access among departing employees in the high eighties as a percentage, and formal processes for revoking machine credentials at offboarding in the low twenties. Those two numbers describe the same gap from opposite ends.",
 "date": "2025-01-20",
 "category": "Developer",
 "author_id": "margot-reyes",
 "tags": [
  "offboarding",
  "residual access",
  "API keys",
  "service accounts",
  "IAM lifecycle",
  "insider risk"
 ],
 "image_title": "Creator Binding Offboarding",
 "schema": "Article",
 "key_takeaways": [
  "2026 studies reported that around 89% of departing employees retained access to at least some corporate applications, and that roughly 20% of organisations have a formal process for offboarding and revoking API keys.",
  "Offboarding operates on the human identity lifecycle. Machine credentials live in dozens of platforms with no back-reference to the creating human.",
  "The measurement worth running: machine credentials created per engineer per year. Almost nobody has it, and it is directly countable per platform."
 ],
 "body": [
  {
   "type": "h2",
   "text": "Two numbers that describe one gap"
  },
  {
   "type": "diagram",
   "kind": "flow",
   "alt": "The engineer leaves; the things they created do not",
   "caption": "Offboarding acts on what HR knows about. It knows about the account.",
   "nodes": [
    {
     "label": "Directory account disabled",
     "note": "HR event",
     "good": true
    },
    {
     "label": "Laptop reclaimed",
     "note": "asset record",
     "good": true
    },
    {
     "label": "Tokens they created",
     "note": "no link to them",
     "bad": true
    },
    {
     "label": "Webhooks, integrations, service accounts",
     "note": "still running",
     "bad": true
    }
   ]
  },
  {
   "type": "p",
   "html": "2026 research on residual access reported that a large majority of departing employees — figures around 89% in one study — retained access to at least some corporate applications after departure. A separate 2026 analysis reported that only around a fifth of organisations have a formal process for offboarding and revoking API keys, with the great majority of secrets remaining valid days after exposure."
  },
  {
   "type": "p",
   "html": "Read those together and the mechanism is obvious. Offboarding is thorough about the things it knows about — directory accounts, email, laptops, badge access — and structurally blind to the things it does not."
  },
  {
   "type": "p",
   "html": "Note the sampling caveat before quoting either figure: these come from vendor studies with their own populations, and the percentages vary considerably between them. The direction is consistent; the precision is not."
  },
  {
   "type": "h2",
   "text": "What a departing engineer actually leaves behind"
  },
  {
   "type": "p",
   "html": "Walk through a realistic four-year tenure. A platform engineer creates, in the ordinary course of work:"
  },
  {
   "type": "ul",
   "items": [
    "Personal access tokens on the source control platform, for local tooling and scripts.",
    "Service accounts in cloud environments, created to make something work on a Tuesday.",
    "Webhooks connecting systems, authenticated by shared secrets in configuration.",
    "API keys for third-party services the team evaluated and adopted.",
    "CI/CD credentials for pipelines they built.",
    "Database users created during a migration and never removed.",
    "OAuth grants to tools they authorised on behalf of the workspace."
   ]
  },
  {
   "type": "p",
   "html": "None of those appears in an offboarding checklist, because no system knows they exist as a set belonging to a person."
  },
  {
   "type": "h2",
   "text": "Why the link does not exist"
  },
  {
   "type": "table",
   "head": [
    "Creation path",
    "Where the credential lives",
    "Creator recorded?"
   ],
   "rows": [
    [
     "Cloud console",
     "Cloud IAM",
     "Sometimes, in audit logs with retention limits"
    ],
    [
     "Source control UI",
     "Platform account",
     "Yes, but not exported to IAM"
    ],
    [
     "Third-party SaaS signup",
     "Vendor system",
     "Only in the vendor's system"
    ],
    [
     "Infrastructure as code",
     "Cloud IAM, via a pipeline identity",
     "<strong style=\"font-weight:600\">No — the pipeline created it</strong>"
    ],
    [
     "Manual script",
     "Wherever it targets",
     "No"
    ]
   ]
  },
  {
   "type": "p",
   "html": "The fourth row is worth dwelling on because it is the fastest-growing path. Infrastructure as code means credentials are created by automation running under a pipeline identity, so the audit log names the pipeline. The human who wrote the code is two systems away."
  },
  {
   "type": "h2",
   "text": "The measurement"
  },
  {
   "type": "p",
   "html": "Before proposing anything, produce the number: <strong style=\"font-weight:600\">machine credentials created per engineer per year</strong>."
  },
  {
   "type": "ol",
   "items": [
    "Pick one platform — the source control system is usually easiest — and export credential creation events with the creating principal for twelve months.",
    "Divide by engineering headcount.",
    "Repeat for the cloud environment and one significant SaaS platform.",
    "Sum. Report it as a range across platforms rather than a single figure."
   ]
  },
  {
   "type": "p",
   "html": "The number is typically in the tens per engineer per year. Multiplied by tenure and headcount, it is the size of the population offboarding does not touch."
  },
  {
   "type": "h2",
   "text": "Creator binding"
  },
  {
   "type": "p",
   "html": "The fix is to make credential creation an act with a signature, so the link exists by construction rather than by log correlation."
  },
  {
   "type": "code",
   "text": "{\n  \"type\": \"manav-stmt/1\",\n  \"action\": \"machine_credential_created\",\n  \"credential\": \"[identifier, platform]\",\n  \"purpose\": \"[why it exists]\",\n  \"scope\": \"[permissions]\",\n  \"notAfter\": \"[expiry]\",\n  \"creator\": \"[named individual, credential assertion]\",\n  \"transferable_to\": \"[team or role, on departure]\"\n}"
  },
  {
   "type": "p",
   "html": "The last field matters operationally. Offboarding should not be a deletion sweep — most of these credentials are load-bearing. It should be a transfer decision, and the transfer target should have been named when the credential was created, by the person who knew what it was for."
  },
  {
   "type": "h2",
   "text": "What offboarding becomes"
  },
  {
   "type": "p",
   "html": "A query rather than an archaeology project. Retrieve every credential the departing engineer signed for, present the list to their manager with the stated purpose and transfer target, and require a decision on each: transfer, or revoke."
  },
  {
   "type": "p",
   "html": "That is a ten-minute conversation instead of a quarterly discovery sweep, and it happens at the moment when the person who knows the answers is still reachable."
  },
  {
   "type": "h2",
   "text": "The uncomfortable first sweep"
  },
  {
   "type": "p",
   "html": "Creator binding only works for credentials created after adoption. Everything that already exists has no creator record, and finding the owners is the archaeology this design exists to prevent."
  },
  {
   "type": "p",
   "html": "There is no clever answer. Run discovery, assign what you can, expire what nobody claims after a notice period, and accept that some of the estate will be orphaned permanently. The value of the design is that the problem stops growing."
  },
  {
   "type": "h2",
   "text": "What survives an offboarding"
  },
  {
   "type": "table",
   "caption": "Artefacts with no link back to the creator",
   "head": [
    "Artefact",
    "Why it survives"
   ],
   "rows": [
    [
     "Personal access tokens",
     "Created under their account, owned by nothing"
    ],
    [
     "CI/CD secrets they added",
     "Owned by the pipeline"
    ],
    [
     "Webhooks to external services",
     "Configured, not owned"
    ],
    [
     "<strong style=\"font-weight:600\">Service accounts they created</strong>",
     "<strong style=\"font-weight:600\">Their own identity, unattributed</strong>"
    ],
    [
     "OAuth grants they approved",
     "Live until revoked"
    ]
   ]
  },
  {
   "type": "h2",
   "text": "Objections and honest limits"
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“We review access on departure.”</strong> You review their account's access. The things they created are not in their account's access list, which is exactly why they survive."
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“This is a discovery problem.”</strong> It is a creation-time problem. Recording who created an identity costs nothing at creation and is impossible to reconstruct afterwards, which is the whole argument."
  }
 ],
 "faq": [
  {
   "q": "Should offboarding revoke everything the person created?",
   "a": "No. Many of those credentials run production. The decision is transfer or revoke, made by someone who knows what the credential does — which is why the purpose and transfer target are recorded at creation."
  },
  {
   "q": "What about credentials created by automation?",
   "a": "They inherit the chain from the human who authorised the automation's scope. The accountable person is the one who signed that delegation."
  },
  {
   "q": "How reliable are the 89% and 20% figures?",
   "a": "They come from vendor studies with their own populations and vary between sources. Use them for direction, and measure your own estate for a number you can defend."
  },
  {
   "q": "Where should we start?",
   "a": "The platform where engineers create the most credentials, which is usually source control. One platform instrumented beats five planned."
  },
  {
   "q": "Why doesn't access review catch these?",
   "a": "Because they are not in the departing user's access list. They were created by that user and are owned by nothing."
  },
  {
   "q": "Can this be fixed retrospectively?",
   "a": "Poorly. Creator binding costs nothing at creation and cannot be reconstructed reliably afterwards."
  },
  {
   "q": "What should happen on departure?",
   "a": "Identities they created expire by default unless explicitly reassigned as a signed act."
  }
 ],
 "sources": [
  {
   "t": "2026 research on residual application access among departing employees."
  },
  {
   "t": "Federal Reserve — Fedwire Funds Service",
   "u": "https://www.frbservices.org/financial-services/wires"
  },
  {
   "t": "FCC — protecting consumers from SIM swap and port-out fraud",
   "u": "https://www.fcc.gov/sim-swap-port-out-fraud"
  },
  {
   "t": "Published insider incident analyses involving credentials created by former employees."
  },
  {
   "t": "OWASP — Non-Human Identities Top 10",
   "u": "https://owasp.org/www-project-non-human-identities-top-10/"
  },
  {
   "t": "NIST SP 800-57 Part 1 Rev. 5 — key management",
   "u": "https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final"
  }
 ],
 "related": [
  {
   "slug": "accountable-ownership-test",
   "title": "Eighty machine identities per human",
   "category": "Developer"
  },
  {
   "slug": "sponsor-accountability",
   "title": "Contractors have no HR record",
   "category": "Compliance"
  },
  {
   "slug": "revocation-latency-framework",
   "title": "Ninety-one percent of leaked secrets still work",
   "category": "Developer"
  },
  {
   "slug": "corporate-espionage-kill-chain-rogue-remote-contractors",
   "title": "Source code exfiltration by people who are supposed to have it",
   "category": "Future of Work"
  }
 ],
 "image": "https://cdn.twc.sh/images/igcache/Creator%20Binding%20Offboarding/1200_630/blog.jpg",
 "wordcount": 1017,
 "url": "/blog/creator-binding-offboarding.html",
 "reading_time": "5 min read",
 "meta_description": "Offboarding disables an account and reclaims a laptop. It does not touch the tokens, keys, webhooks and service accounts the leaver created.",
 "hub": {
  "slug": "topics/machine-identity",
  "title": "Machine and signing identity"
 },
 "answer": "A directory account and a laptop. It does not touch the personal access tokens, integration keys, webhooks and service accounts the departing engineer created, because those are not linked to their identity in any system — they were created by them and belong to nothing.",
 "answer_q": "What does offboarding actually remove?",
 "glossary": [
  {
   "term": "Personal access token",
   "def": "A credential created by a user for programmatic access, which typically outlives their account."
  },
  {
   "term": "Creator binding",
   "def": "Recording which human created an identity or credential, at the moment of creation."
  },
  {
   "term": "Reassignment",
   "def": "Transferring accountability for an identity to a new owner — which should be an explicit act."
  }
 ],
 "checklist": {
  "title": "Binding creation to the creator",
  "id": "creation",
  "desc": "Four steps.",
  "steps": [
   {
    "name": "Record the creating human on every identity.",
    "text": "At creation, as a signed fact."
   },
   {
    "name": "Make departure trigger a review of what they created.",
    "text": "Not only what they could access."
   },
   {
    "name": "Expire creator-bound identities on departure by default.",
    "text": "Unless explicitly reassigned."
   },
   {
    "name": "Reassign as a signed act.",
    "text": "So the new owner accepts it knowingly."
   }
  ]
 },
 "cta": {
  "title": "Where this fits in Manav",
  "html": "Manav anchors every machine and agent identity to a named human through a signed delegation with scope, expiry and enforced revocation — so the chain from an action to a person survives the identity outliving its creator.",
  "href": "../docs.html",
  "label": "See delegation chains"
 }
}