Small and mid-sized businesses run on API keys, service accounts and app integrations that nobody has listed, and most have no budget or staff for an NHI platform. A typical small company has a cloud account or two, a Microsoft 365 or Google Workspace tenant, a code repository, an accounting system linked to the bank, a CRM with a dozen connected apps and an IT provider holding admin access to all of it. Each link is a non-human identity (NHI) with a credential that can be stolen, and the same OWASP risks that hit large enterprises apply. This guide sets out a minimum viable programme: what to inventory, the few rules that remove most of the risk, the free platform features that enforce them, and a quarterly routine that one person can run. It is written for IT leads, founders, MSPs and part-time security owners in organisations of roughly 10 to 500 people; larger programmes should follow the NHI Programme Roadmap Guide.
Key takeaways
- A spreadsheet is enough to start. In our view at NHI Mgmt Group, an inventory with owner, purpose, credential type and expiry is enough for most SMB estates and is the foundation for everything else.
- Five rules remove most of the risk. One owner per NHI, no secrets in code or chat, no shared or reused credentials, least privilege, and every credential has an end date.
- Use what you already pay for. Cloud and code platforms include roles, managed identities, key creation blocks and secret scanning that replace long-lived keys at no extra cost.
- Offboarding is the highest-value process. When a person, supplier or app leaves, the NHIs they created or held must be rotated or removed the same week.
- A quarterly hour beats a yearly project. A short, scheduled review of new, expiring and unused NHIs keeps the inventory true without dedicated tooling.
What counts as an NHI in a small business
An NHI is any identity used by software rather than a person: an account, key, token, certificate or app registration that lets one system act on another. In a small business they usually fall into a handful of groups.
| Type | Common SMB examples | Where to look |
|---|---|---|
| Cloud keys and service accounts | Access keys for backups or a website deploy, service account keys for an analytics job | Cloud console IAM pages, access key and key age reports |
| App registrations and OAuth apps | Apps connected to Microsoft 365 or Google Workspace for e-signature, scheduling, backup or email marketing | Identity admin console: registered apps, enterprise apps, third-party app access |
| SaaS API keys and integration users | CRM to marketing platform, accounting to payments, helpdesk to chat | Each SaaS admin page for API keys, connected apps and integration users |
| Code and CI/CD credentials | Personal access tokens, deploy keys, pipeline secrets | Repository and organisation settings, pipeline secret stores |
| Shared and service logins | Database login used by a reporting tool, a "scanner@" mailbox for the printer, an "admin" account an MSP uses | Directory, password manager shared folders, supplier contracts |
| Certificates and domain credentials | TLS certificates, DNS provider API tokens, email sending keys | Registrar and DNS accounts, certificate expiry notices |
The OWASP Non-Human Identities Top 10 (2025) describes the risks these carry. For a small business the ones that matter most are NHI1 Improper Offboarding, NHI2 Secret Leakage, NHI3 Vulnerable Third-Party NHI, NHI5 Overprivileged NHI, NHI7 Long-Lived Secrets and NHI10 Human Use of NHI.
Step 1: build the inventory without tooling
Start with a shared spreadsheet or a table in the tool you already use for IT records. NIST SP 800-53 CM-8 System Component Inventory and IA-4 Identifier Management are the controls this evidences, and NIST CSF 2.0 ID.AM-02 asks for inventories of software, services and systems. Keep the columns short so the sheet is maintained.
| Column | Why it matters |
|---|---|
| Name and platform | Identifies the NHI without exposing the secret (never store secret values in the inventory) |
| Purpose | One line; if nobody can write it, the NHI is a removal candidate |
| Owner (a named person) and backup owner | Someone to ask before rotation and to act on offboarding |
| Credential type | Role or managed identity, certificate, client secret, API key, password, token |
| Created and expires | Drives the renewal calendar; "never" is a finding |
| Access level | Admin, read-write or read-only, in plain words |
| Where the secret is stored | Password manager entry, secrets manager, platform-held, or "unknown" |
| Last used and last reviewed | Supports removal of unused identities and shows the review happened |
Fill it platform by platform in a single working week: identity tenant, cloud accounts, code platform, finance and CRM systems, then suppliers. Ask each team lead "what connects to what you run?" and check the answers against admin consoles. Add a row for every key you find in a password manager's shared folders. See the NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments for where enterprise tools look, most of which can be checked by hand at small scale.
Step 2: the five rules
Write these on one page, agree them with leadership and any MSP, and apply them to new NHIs straight away. The NHI Policy Template is a fuller version if you need one later.
- Every NHI has a named owner. No owner after one review cycle means disable, wait two weeks, then delete. NIST CSF 2.0 GV.RR-02 covers roles and responsibilities.
- No secrets in code, documents, email or chat. Secrets live in the platform's own store, a secrets manager or a business password manager. This addresses OWASP NHI2 Secret Leakage and NIST SP 800-53 IA-5(7).
- One credential per application and environment. No shared logins between systems, no test credential that also works in production, and no staff signing in as the integration user (OWASP NHI8, NHI9 and NHI10).
- Least privilege. Read-only unless writing is needed; admin only with a written reason (NIST SP 800-53 AC-6, CSF PR.AA-05).
- Every credential has an end date. Prefer credentials the platform issues and expires automatically; otherwise set an expiry or a calendar rotation date in the inventory (OWASP NHI7).
Step 3: use the platform features you already have
The fastest wins come from replacing stored keys with credentials the platform issues for you. The table lists, for common SMB platforms, each vendor's own documented setting. Platforms are listed alphabetically; the order is not a ranking, and each has its own deeper guide on this site.
| Platform | Prefer instead of stored keys | Settings to apply | Further reading |
|---|---|---|---|
| Amazon Web Services (AWS) | IAM roles, which AWS documents as delivering temporary credentials to workloads on services such as EC2 and Lambda; IAM Roles Anywhere or web identity federation for workloads outside AWS | Use IAM "access last used" and "last accessed" information to remove unused keys and permissions; update long-term keys when needed, for example when an employee leaves; IAM Access Analyzer can generate least-privilege policies from CloudTrail activity | AWS Access Keys Security Guide |
| GitHub | Repository and organisation secrets in place of tokens in code; OIDC federation from Actions to cloud providers | Secret scanning runs automatically for free on public repositories; push protection for users is on by default for pushes to public repositories; private organisation repositories need GitHub Secret Protection (GitHub Team or Enterprise Cloud) | GitHub Personal Access Tokens Security Guide |
| Google Cloud | Attached service accounts or Workload Identity Federation in place of downloaded service account keys | Enforce the organisation policy constraints "Disable service account key creation" and "Disable service account key upload" at the organisation root, with exceptions only where no alternative exists; use key expiry for temporary access only, and rotation for production | Google Cloud Service Account Keys Security Guide |
| Microsoft Entra ID | Managed identities for Azure resources, which Microsoft describes as the better option where the service supports them; certificates (recommended) in place of client secrets for app registrations | Review Entra ID > App registrations > Certificates & secrets for each app's credential expiry; client secret values are shown once at creation, so store them straight into a vault | Azure Entra Client Secrets Security Guide |
For SaaS applications without these features, generate one API key per integration, choose the narrowest scope offered, record it in the inventory and store it in the password manager or secrets manager. Where a SaaS tool supports OAuth app connections instead of a pasted key, the connection can usually be reviewed and revoked from the admin console.
Step 4: offboarding and suppliers
OWASP ranks Improper Offboarding first in its NHI Top 10. In small firms the trigger is usually a person leaving or a supplier contract ending, not a system being retired.
- Staff leavers: filter the inventory by owner and creator. Reassign ownership, rotate any credential the person could read (including shared password manager entries), and revoke personal access tokens and app consents they granted. See the Employee Offboarding Security Guide.
- Suppliers and MSPs: list every account, key and delegated admin relationship each supplier holds; at contract end remove them and rotate anything shared. See Choosing an IT Support Provider or MSP Securely and the GDAP and MSP Delegated Admin Access Guide.
- Retired apps: when you stop paying for a SaaS tool, remove its connected app, revoke its API keys at the other end and delete its row.
- Disable, then delete: NIST SP 800-53 AC-2(3) Disable Accounts supports a disable-first pattern; leave a short window to catch anything that breaks before deletion.
Step 5: the quarterly routine
One person, about an hour a quarter for a small estate, more for a few hundred NHIs. Put it in the calendar.
- Export new app registrations, connected apps, cloud keys and repository tokens created since the last review and add missing rows.
- List credentials expiring in the next 90 days and book their renewal with the owner.
- Find NHIs not used for 90 days using each platform's last-used data; disable those with no owner response.
- Check for any credential with admin rights and confirm the reason still holds.
- Review secret scanning alerts and close each one by rotation, not only by deleting the commit.
- Ask each owner to confirm their rows (a reply to an email is enough evidence at this scale).
- Record the date and the count of changes in the inventory.
Choosing how far to go
| Organisation profile | Minimum | Next step when ready |
|---|---|---|
| Under 50 staff, SaaS only, MSP-run | Inventory, five rules, leaver step, MSP access list; secrets in a business password manager | Annual review of connected apps with the MSP |
| 50 to 200 staff with one cloud account and in-house developers | All of the above plus roles or managed identities for workloads, secret scanning and push protection on code | A secrets manager for application secrets; federation from CI/CD |
| 200 to 500 staff, several clouds, regulated data | All of the above plus quarterly owner attestation and key creation blocks | Move to the enterprise roadmap and consider NHI tooling |
A password manager is a reasonable secret store for a few dozen SaaS keys used by people configuring integrations. Once applications fetch secrets at runtime, a secrets manager or the cloud platform's own store is the better fit, because it gives programmatic access, audit logs and rotation. See the Secrets Management Guide.
Leaked credential response for small teams
- Revoke or rotate first: issue the replacement, update the application, revoke the old credential. Google's guidance is explicit that a key committed to a repository must be deleted in IAM, because removing it from the repository is not enough.
- Check use: review the platform's activity logs for the credential since it was exposed.
- Clean up: remove the secret from the code, document or chat where it appeared.
- Escalate: unexpected use, or access to personal data, moves this to your incident process and your MSP or insurer contact.
See the Leaked Credential Response Playbook for the longer version.
Measuring progress
- Owner coverage: percentage of inventory rows with a named owner (target 100% for admin-level NHIs).
- Credentials with no end date: count, trending down each quarter.
- Stored keys replaced: number of cloud keys and client secrets moved to roles, managed identities, federation or certificates.
- Leaver closure time: days from a person or supplier leaving to their NHIs being rotated or removed.
- Open secret scanning alerts: count and age.
Framework mapping
| Activity | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | OWASP NHI Top 10 (2025) |
|---|---|---|---|
| Inventory | ID.AM-02 | CM-8, IA-4 | Supports all |
| Owners and policy | GV.RR-02 | AC-2 | NHI1, NHI10 |
| No secrets in code or chat | PR.AA-01 | IA-5, IA-5(7) | NHI2 |
| Least privilege and separation | PR.AA-05 | AC-6 | NHI5, NHI8, NHI9 |
| End dates and platform-issued credentials | PR.AA-01 | IA-5 | NHI4, NHI7 |
| Offboarding | PR.AA-05 | AC-2(3) | NHI1, NHI3 |
Common failure patterns
- Secret values in the inventory: the register becomes the most valuable file in the company. Record where a secret lives, never the secret.
- The MSP's master account: one supplier account with admin rights everywhere, shared by their staff, with no record on your side.
- Staff using the integration user: people sign in as the API account to "fix" data, which hides who did what and keeps the password in circulation.
- Deleting the commit instead of the key: the leaked secret stays valid, and copies remain in forks and clones.
- A one-off clean-up: an inventory built once and never reviewed is out of date within a quarter.
- Expiry with no calendar: certificates and client secrets expire unexpectedly, causing an outage that teaches people to choose "never expires".
Practitioner checklist
- Create the NHI inventory with owner, purpose, credential type, expiry, access level and storage location.
- Agree the five rules with leadership and your MSP.
- Replace cloud access keys and service account keys with roles, managed identities or federation where the platform supports it.
- Block new service account key creation where your cloud platform offers an organisation policy for it.
- Turn on secret scanning and push protection on code repositories.
- Move remaining secrets into a password manager or secrets manager and out of code and chat.
- Add NHI rotation and removal to staff and supplier offboarding.
- Run and record the quarterly review.
Standards and references
- OWASP: Non-Human Identities Top 10 (2025)
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- AWS: Security best practices in IAM
- GitHub Docs: About secret scanning
- Google Cloud: Best practices for managing service account keys
- Microsoft Learn: Register a Microsoft Entra app and create a service principal
Related NHI Mgmt Group resources: NHI Programme Roadmap Guide · NHI Governance Maturity Model · NHI Policy Template · Secrets Management Guide · NHI Offboarding and Decommissioning Guide