Accounts and access checklist before going live

Summary

This checklist helps you confirm accounts and access are in good shape before you go live or hand off a system. It covers SSH keys and 2FA, passwords and API tokens, least-privilege access, and recovery and revocation so you reduce lockout risk and avoid leaving default or overbroad access in place. Use it once before launch and optionally on a schedule (e.g. quarterly) for critical systems.

Prerequisites

• You have (or can get) access to the systems that will be live: servers, GitHub/version control, cloud console, CI/CD, and any shared accounts or apps.
• You have already set up SSH keys and 2FA where applicable (see the linked guides) or can do so as part of this checklist.
• You can run one end-to-end test (e.g. deploy or a critical user flow) after the checks.

Steps

Step 1: SSH and 2FA in place

• Servers: Access is via SSH with key-based auth where possible; password login disabled or restricted. No shared private keys; each person or role has its own key or access path.
• GitHub (or main VCS): Team members use SSH keys (or equivalent) for git; 2FA is enabled on their accounts. Org/repo access is via teams or explicit grants, not a single shared account.
• Critical accounts (e.g. cloud, domain, billing): 2FA enabled; recovery or backup codes saved in a safe place (password manager or secure backup), not only on one device.
• Recovery: You know how to regain access if the primary 2FA device is lost (recovery codes, backup method, or account recovery flow) and have tested it once.

Step 2: Passwords and API tokens under control

• No defaults: Default or factory passwords (e.g. admin/admin, root/install) have been changed or the service is not exposed.
• No shared passwords in the clear: Shared logins use a password manager or restricted vault; the same password is not reused for multiple systems.
• API keys and tokens: Created per service or use; stored in a secrets manager, CI secrets, or env vars injected at runtime — not in repo code or config committed to git.
• Rotate if unsure: If any shared or long-lived credential might have been exposed, rotate it and update the systems that use it before go-live.

Step 3: Least-privilege and roles

• People: Each person has only the access they need (e.g. read-only vs push, viewer vs admin). Unused or broad roles removed or downgraded.
• Services and automation: CI/CD, deploy bots, and integrations use dedicated tokens or service accounts with minimal scope, not a human’s full-access token.
• Document who has what: Short list or table (e.g. “Repo X: A and B have push; C has read”) so you can audit and revoke later. Update it when you add or remove people.

Step 4: Recovery and revocation ready

• Password reset: You know how to reset passwords for critical accounts (admin, deploy, DB) and who is allowed to do it.
• 2FA recovery: Recovery codes or backup methods for critical accounts are stored safely and have been used once in a test so you know the process.
• Offboarding: You have a short procedure (or link to one) for when someone leaves: revoke SSH keys, remove from orgs, rotate shared secrets they knew. Assign an owner (e.g. How to revoke access when someone leaves).

Step 5: One end-to-end check and a record

• Run one full path: E.g. clone repo with SSH, run deploy, or log in to the app/server as the role that will be used in production. Fix any blockers you find.
• Record: Note the date and what you checked (e.g. “Pre-launch checklist: SSH, 2FA, tokens, roles, recovery — 2026-02-07”). Keep it in a runbook or wiki so you can repeat or audit later.

Verification

• Every item you need for go-live is checked or explicitly deferred with a reason.
• At least one person (or role) can complete the critical path (e.g. deploy or admin login) using the intended access (keys, 2FA, tokens).
• Recovery and revocation are documented and have been tried once (e.g. used one recovery code, or ran through the offboarding steps in a test).

Troubleshooting

“We don’t have 2FA on service X”
Enable it before go-live if the service holds sensitive data or control. If the service does not support 2FA, use a strong password, restrict IP or VPN access if possible, and ensure the password is not shared in plain text.

“Secrets are already in the repo”
Treat them as compromised. Rotate the secrets, move them to a vault or CI secrets, remove the old values from history (e.g. git filter-branch or BFG) or restrict repo access, and add a pre-commit or scan to prevent committing secrets again.

“Too many people have admin”
List current admins and reduce to the minimum needed for launch. Move the rest to a lower role (e.g. developer, viewer). Document who is admin and why; review again after launch.

Next steps

• When someone leaves: How to revoke access when someone leaves.
• If you hit permission issues: Access denied: how to fix permission errors.