Skip to main content

CC6.5 — Logical and physical access removal on termination or role change

Status: Partially implemented (technical revocation paths live; offboarding runbook target week 13) Owner: Agent #38 (Senior Compliance Lead, SOC 2 + ISO 27001) Last reviewed: 2026-05-28 Next review: 2026-08-28

Trust Services Criteria reference​

The entity discontinues logical and physical protections over physical assets only after the ability to access information assets has been removed. The control covers the offboarding sequence (immediate revocation on termination, day-aligned revocation on role change), the change-of-role grant adjustments, and the audit trail of revocation actions.

How ZeroAuth meets this control​

The credential surfaces requiring revocation on offboarding (or scope adjustment on role change) and the named revocation procedure per surface:

  • VPS SSH access — root (laptop key) and zeroauth-deploy (CI key) are the only authorised principals per docs/threat_model.md "Threat surface inventory". Revocation = remove the offboarded fingerprint from ~/.ssh/authorized_keys on the VPS. Today this requires a manual step by an SRE; the runbook target is week 13 (2026-08-17).
  • GitHub Enterprise Cloud — source-code host. Revocation = remove user from the GitHub organisation through the admin console. Reflects within minutes; outstanding clones on the offboarded device are not invalidated (compensating control: rotate any SSH-key-based deploy credentials that were used by that user).
  • Google Workspace SSO — identity provider for shared services. Revocation = suspend / delete the Google account through the workspace admin centre. Reflects on next OAuth refresh; access typically revoked within an hour.
  • 1Password vault — password manager + secrets vault. Revocation = remove user from the 1Password team / vault. Sensitive secrets stored in 1Password are not exfil-resistant against an offboarded user who has the secret cached; compensating control: any secret known to an offboarded user is rotated within 24 hours of offboarding.
  • Production .env secrets on VPS — stored at /opt/zeroauth/.env; never enter the repo per CLAUDE.md §"Never commit secrets". Rotation = generate new secrets, update VPS, restart services. Tied to GitHub Actions secrets via the deploy.yml workflow.
  • Console JWTs (developer console) — JWT signing-key rotation invalidates all outstanding tokens (RS256 + key rotation playbook is audit finding C-11 sprint-2 deliverable; today HS256 makes the rotation a service-affecting event).
  • API keys (tenant /v1/*) — revocation via the console; SHA-256 hash of the old key gets a revoked_at timestamp. The lookup logic checks revocation status before authorisation. Threat-model row A-06 ("replay of revoked API key after restart") is the failure mode to watch — the closure depends on the in-memory session store being replaced by the Postgres session store (audit finding C-9).
  • Smart-contract deployer wallet — held by Agent #25; rotation via npm run wallet:rotate. The wallet is the single onlyOwner on DIDRegistry. HSM-backed signer migration (D-Q4-06, week 48) eliminates the human-custody dimension.

The audit trail of revocation actions is the audit_events table. The audit chain (ADR 0013, commit 27ed93c + commit a475ed8) and the on-chain anchor (ADR 0014, commit d6c6a4e) make a tamper-resistant record of every revocation. Direct INSERT INTO audit_events is blocked by tests/audit-chain.test.ts::"every audit-writing surface uses appendAuditEvent" (commit c09c081).

Role-change scope adjustment is handled at the issuance layer for tenant API keys (issue a new key with the adjusted scope set; revoke the old) and at the console-role grant for console users (today, single-tenant-admin role; multi-role console is a Phase 1 deliverable). For SSH + GitHub + Google + 1Password the role-change is an HR + IT action that triggers the same revocation runbook.

The quarterly access review (compliance roadmap D-Q2-12, D-Q3-16, D-Q4-07) is the periodic check that the revocation set matches the role set. First review target week 26 (2026-11-09) with Agent #36 + Agent #21.

The R-COMP-07 risk (auditor key personnel change mid-engagement) is the vendor-side analogue; mitigation is the named-lead-auditor + substitute clause in the engagement letter.

Evidence references​

  • docs/threat_model.md "Threat surface inventory" — VPS access principals.
  • docs/threat_model.md row A-06 — replay-of-revoked-API-key threat surface.
  • docs/security/audit-findings.md C-9 (in-memory session store) + C-11 (HS256 JWT rotation) — open dependencies on revocation completeness.
  • CLAUDE.md §"Never commit secrets" — secrets handling.
  • ADR 0013-audit-log-hash-chain.md (commit 27ed93c) — tamper-evident revocation log.
  • Commit a475ed8 — audit-chain implementation.
  • Commit c09c081 — direct-insert prevention.
  • Commit d6c6a4e — AuditAnchor contract.
  • docs/compliance/compliance-roadmap-v1.md §4 D-Q2-12, D-Q3-16, D-Q4-07 — quarterly access reviews.
  • docs/compliance/compliance-roadmap-v1.md D-Q4-06 — HSM signer migration.

Open gaps + remediation roadmap​

  • Written offboarding runbook (docs/operations/offboarding-runbook.md) — sequence + SLA per credential surface; target week 13 (2026-08-17).
  • JWT key rotation playbook (docs/operations/jwt-key-rotation-playbook.md) — audit finding C-11 sprint-2 deliverable; required for low-disruption console-JWT rotation.
  • Postgres-backed session store — audit finding C-9 sprint-2; closes A-06 (replay of revoked API key).
  • Quarterly access review v1 — D-Q2-12, target week 26.
  • Automated provisioning + deprovisioning (SCIM / Workday integration) — Phase 4 deliverable; today all role-change actions are manual.

Test or audit query​

For an offboarded test user, the auditor walks the runbook:gh organization members | grep <user> returns empty; the Google admin centre shows Suspended; 1Password shows removed; the VPS authorized_keys does not contain the user's key fingerprint; audit_events shows a revocation row with chain link intact.