Startup Identity and Secrets Security Guide: The First Controls to Get Right

Startups rarely get breached through clever exploits; they get breached through a founder's reused password, an AWS key committed to GitHub or an ex-contractor who still has access. In a ten-person company almost everyone is an administrator of something, and every API key is a production key. This guide sets out the first identity and secrets controls a small engineering-led team should put in place, in the order that gives the most protection for the least effort: SSO and MFA, a password manager, the cloud root account, GitHub organisation settings, secrets in CI, offboarding, and the basics that make a first SOC 2 audit straightforward. It is written for founders, first engineering and IT hires, and fractional security leads.

Key takeaways

• Identity provider first. Pick one identity provider (usually your email suite) and make it the front door to every tool that supports SSO; it turns onboarding, MFA and offboarding into one place to manage.
• Phishing-resistant MFA for admins from day one. Security keys or passkeys on founder, cloud and GitHub owner accounts cost little and close the most common takeover route.
• Lock the cloud root account away. No access keys, MFA held separately from the password, and alerts on every root sign-in.
• Secrets never live in code. Turn on push protection, use OIDC federation instead of cloud keys in CI, and keep everything else in a secrets manager or password manager vault.
• Offboarding is where small teams fail. Contractors, personal tokens and shared passwords outlive the people who created them unless someone owns a written leaver checklist.

Why startups are different

• Few people, broad access: early employees hold admin rights in the cloud, the code host, the payment provider and the customer database at once. Each account is a path to everything.
• Machine identities outnumber people early: CI tokens, cloud keys, third-party API keys and OAuth apps multiply faster than headcount, and nobody owns them. See the API Key Management Guide.
• Contractors and personal accounts: freelancers often join with personal GitHub or Google accounts and leave without a formal exit.
• Customers ask early: the first enterprise deal usually brings a security questionnaire and a request for SOC 2 or similar assurance. Controls built now become audit evidence later.

The aim is not an enterprise programme. It is a short list of defaults that are cheap when the company has five people and expensive to retrofit when it has fifty. The Small Business Identity and Access Security Guide covers non-technical small firms; this guide assumes a software company with cloud infrastructure and source code.

The first controls, in order

SSO, MFA and the password manager

Choose one identity provider

For most startups the identity provider is Google Workspace or Microsoft Entra ID, because it already holds everyone's email. Connect every SaaS tool that supports SAML or OIDC SSO, and treat the identity provider's super administrator accounts as the most sensitive in the company. If a tool only offers SSO on an expensive tier, record that decision and protect the local login with the password manager and MFA instead. See the Identity Provider and SSO Security Guide and the Google Workspace Security Guide.

Enforce MFA, then make it phishing-resistant

• Google Workspace: in the Admin console go to Security, Authentication, 2-step verification. Set an enforcement date, a short new user enrolment period (it can be set from 1 day to 6 months; keep it to days), and choose the allowed methods. "Any except verification codes via text, phone call" removes SMS; "Only security key" requires a security key or passkey and needs a suspension grace period and backup codes planned in advance.
• Admins first: put founders, identity provider administrators, cloud administrators and GitHub owners on security keys or passkeys immediately. Give each person two keys and keep the spare somewhere safe.
• Everyone next: remove SMS for the whole company once people have moved to an authenticator app or passkey.

See the Phishing-Resistant MFA Guide and the Hardware Security Keys Guide.

Password policy that matches current guidance

NIST SP 800-63B-4 sets the modern baseline: passwords used on their own must be at least 15 characters (at least 8 when used only alongside another factor), no composition rules, no forced periodic changes unless there is evidence of compromise, a check against lists of common and breached passwords, and verifiers must allow password managers and autofill. A company password manager makes this easy: generated passwords for every account, shared vaults per team for the logins that cannot use SSO, and the master account protected with a security key. See the Password Manager Buyer's Guide.

Cloud root account and cloud access

The cloud root or owner account can delete everything, including backups, and change billing. AWS's own root user guidance is a good template for any provider:

• Use it only for root-only tasks: daily work happens through individual identities federated from the identity provider (AWS IAM Identity Center or equivalent), never through the root account or shared IAM users.
• No root access keys: AWS says not to create them. Delete any that exist.
• Strong password and MFA, held apart: a unique generated password and MFA (AWS supports FIDO security keys, hardware TOTP tokens and virtual MFA, up to eight devices). AWS recommends that no single person controls both the password and the MFA device.
• Group email and recovery: register the root account to a company group address used for nothing else, and give the recovery phone number and the inbox to different people.
• Multiple accounts early: once you have production data, use AWS Organizations with separate production and development accounts. AWS recommends centrally managing root access for member accounts, which removes their root credentials, plus a service control policy that denies root actions. See the AWS Organizations and SCPs Guide.
• Alert on root use: an EventBridge rule with SNS notification on root sign-in, GuardDuty root credential usage findings, and AWS Config or Security Hub checks for root MFA and access keys.

The same thinking applies to Google Cloud organisation administrators and Azure Global Administrators. Keep one documented break-glass account per platform. See the Break-Glass Account Guide, the AWS IAM Policies and Roles Guide and the Top 10 AWS IAM Mistakes.

GitHub organisation settings

Source code is where secrets leak and where attackers with a stolen token can plant code. These settings take an afternoon.

Use company-managed accounts or require contractors to be added as outside collaborators with access only to the repositories they need. See the GitHub and GitHub Actions Security Guide. The Uber 2016 breach began with an AWS key in a private GitHub repository: private does not mean safe.

Secrets in code, CI and runtime

Where each kind of secret should live

Replace CI cloud keys with OIDC

GitHub Actions can request an OIDC token per job, and AWS, Azure, Google Cloud and HashiCorp Vault can exchange it for a short-lived credential that is valid for that single job. The cloud role's trust policy checks claims such as the subject, for example repo:<org>/<repo>:environment:production, so only the right repository and environment can assume it. This removes the most valuable long-lived secret most startups have. See the CI/CD Pipeline Identity Security Guide.

Handle leaks in the right order

OWASP's Secrets Management Cheat Sheet sets the order: revoke the exposed secret immediately, rotate to a new one, remove it from the exposed location (code, history, logs), then record who had access and when it was used. Deleting the commit first is the common mistake: the secret is already copied. See the Secrets Management Guide and the Secrets Rotation Runbook Template.

Joiners, leavers and contractors

1. Joiner: create the identity provider account first, then add the person to groups that grant SSO access. Avoid creating local accounts in tools by hand.
2. Role change: remove old group memberships the same day new ones are added.
3. Leaver, same day: suspend the identity provider account (which ends SSO sessions), remove the person from the GitHub organisation, revoke their personal access tokens and SSH keys, and remove them from password manager vaults.
4. Leaver, within a week: rotate any shared secret they could see (shared vault items, CI secrets, API keys they created), transfer ownership of documents and OAuth apps, and recover hardware.
5. Contractors: set an end date when access is granted, prefer company-issued accounts, and review contractor access monthly.

The Coupang breach shows the cost of a former engineer's signing key that was never revoked. See the Employee Offboarding Security Guide and the NHI Offboarding and Decommissioning Guide.

SOC 2 readiness basics

SOC 2 is an attestation report by an independent CPA firm against the AICPA Trust Services Criteria (security, availability, processing integrity, confidentiality and privacy; security is always in scope). A Type 1 report assesses control design at a point in time; a Type 2 report tests operating effectiveness over a period, commonly several months. Identity and secrets controls make up a large share of the logical access criteria auditors test. The controls in this guide produce the evidence they ask for:

• Access provisioning and removal: joiner and leaver tickets with timestamps, matched against identity provider logs.
• Authentication: screenshots or exports showing enforced MFA in the identity provider, GitHub and cloud.
• Access reviews: quarterly sign-off of who has admin rights in each critical system.
• Secrets and encryption: secrets manager configuration, push protection settings and rotation records.
• Policies: a short access control policy and acceptable use policy that describe what you actually do.

Start collecting evidence now even if the audit is a year away; a Type 2 period needs controls already running. See the SOC 2 Guide. For UK customers, the NCSC's Cyber Essentials scheme covers five technical controls (firewalls, secure configuration, security update management, user access control and malware protection) and is a lighter first certification.

Detection and measurement

• Log sources to keep: identity provider sign-in and admin audit logs, cloud audit logs (CloudTrail or equivalent) in a separate account or bucket, GitHub organisation audit log, and secret scanning alerts.
• Alerts worth having on day one: cloud root sign-in, new cloud access keys created (T1098.001 Additional Cloud Credentials), MFA disabled on any account, new GitHub owner, push protection bypass, new OAuth app granted organisation-wide access.

Common failure patterns

• Keys in repositories: a cloud key committed "just for now", like the Toyota T-Connect key that sat on public GitHub for five years.
• No MFA on a critical SaaS login: the Snowflake customer breaches used infostealer credentials on accounts without MFA.
• Long-lived keys parked in CI: admin cloud keys stored in a CI platform's secret store become someone else's problem until that platform is breached; after the CircleCI breach exposed customers' CI/CD secrets, every customer holding static keys there had to rotate them.
• Root account used daily: shared root credentials with no MFA, so nobody can tell who did what.
• Deleting instead of revoking: removing the leaked commit but leaving the key live.
• Forgotten leavers: contractors and personal tokens that survive the end of a contract.

Framework mapping

CIS Implementation Group 1 (56 safeguards aimed at small organisations with limited security staff) is a sensible next target once the controls above are in place.

Practitioner checklist

• Connect every tool that supports it to one identity provider and enforce MFA there.
• Issue two security keys to every founder and administrator and require them for admin accounts.
• Roll out a company password manager and move shared logins into team vaults.
• Delete cloud root access keys, split root password and MFA between two people, and alert on root sign-in.
• Require secure-only 2FA, a PAT policy and push protection in the GitHub organisation.
• Replace cloud keys in CI with OIDC federation and move runtime secrets to a secrets manager.
• Write a joiner and leaver checklist with a named owner and test it on the next departure.
• Turn on audit logs for identity provider, cloud and GitHub, and set the day-one alerts.
• Run a quarterly admin access review and keep the evidence for SOC 2.

Standards and references

• NIST: SP 800-63B-4 Authentication and Authenticator Management
• AWS: Root user best practices for your AWS account
• GitHub Docs: Requiring two-factor authentication in your organization
• GitHub Docs: About push protection
• GitHub Docs: About security hardening with OpenID Connect
• OWASP: Secrets Management Cheat Sheet
• CIS: Implementation Group 1
• NCSC: Cyber Essentials overview

Related NHI Mgmt Group resources: Secrets Management Guide · MFA Guide · Top 10 Secrets Management Mistakes · SOC 2 Guide · CI/CD Security Guide