When an integration needs access, teams usually hand it whatever the platform offers first, often an API key, and only later find that nobody can say which system used it, what it can reach or who owns it. An API key and a service account are different kinds of thing: one is a credential, the other is an identity that can hold credentials and permissions. This guide compares them for integrations (internal services, SaaS connections, CI/CD jobs, partner access and AI agents), sets out the risks of each, gives a decision table by scenario and a migration path from shared keys to scoped service identities. It is for platform engineers, integration owners and IAM teams. Platforms used as examples are listed alphabetically. For key lifecycle detail see the API Key Management Guide; for how keys compare with OAuth tokens see the API Keys vs OAuth Tokens Guide.
Key takeaways
- A key is a credential, a service account is an identity. A service account is a principal you can grant roles to, audit and disable; an API key is a string that may or may not map to any principal.
- Some API keys identify nobody. Google Cloud states that a standard API key does not identify a principal, so IAM cannot check whether the caller is authorised; it only ties the request to a project for billing and quota.
- Service accounts are only as safe as their credentials. A service account with a downloaded key or a password in a script has the same leak risk as an API key, plus whatever roles it holds.
- Prefer platform-issued credentials. Attached service accounts, managed identities, federation and app installations with short-lived tokens remove the stored secret altogether.
- Keys still have a place. Publishable or quota-only keys, simple third-party APIs that only offer keys, and short-lived testing can use keys, provided they are restricted, owned, logged and rotatable.
What each one actually is
An API key is a secret string issued by an API provider. The caller sends it with each request and the provider looks it up. There is no standard: scoping, expiry, IP restriction and logging are whatever that provider built. Keys fall into three broad types:
- Identifier keys: associate a request with an account or project for quota and billing. Google Cloud standard API keys are this type, and Google says the key does not identify a principal.
- Account keys: act with the full rights of an account. Stripe's secret keys (
sk_) have unrestricted permissions on all Stripe APIs, and Stripe does not recommend them for new use. - Scoped keys: carry a defined permission set. Stripe restricted keys (
rk_) and Google Cloud keys with API and application restrictions are examples.
A service account is a non-human account inside an identity system. Google Cloud defines it as a non-human account, typically used by an application or workload, identified by an email address and acting both as a principal (it can be granted roles) and as a resource (others can be granted rights to use it). Kubernetes describes a service account as a non-human account that provides a distinct identity in a cluster. In Microsoft Entra the equivalent is a service principal or a managed identity; in Active Directory it is a user or managed service account used by software. A service account authenticates with one of several credential types: a password, a downloaded key, a certificate, or a credential issued by the platform at runtime.
So the real comparison is three-way: a raw API key, a service account with a stored credential, and a service account with a platform-issued credential. Most of the risk difference sits between the second and third.
Side-by-side comparison
| Property | API key | Service account with stored secret (password, key file, client secret) | Service account with platform-issued credential |
|---|---|---|---|
| Is it a principal? | Sometimes; identifier keys are not | Yes | Yes |
| Permissions model | Provider-specific; often all or nothing, sometimes scoped | Roles or groups in the identity system, reviewable | Same as stored-secret service account |
| Typical lifetime | Until revoked; some providers support expiry or scheduled rotation | Months to years unless rotated | Minutes to hours, renewed automatically |
| Where the secret lives | Config, environment variables, vaults, too often code | Key files, vaults, scripts | Nowhere you manage: metadata service, token projection, federation |
| Attribution in logs | Key ID or account; may not show which system called | Account name per request | Account name, often with the workload or resource that obtained it |
| Network restriction | Provider-specific (IP, referrer, app, ASN rules) | Conditional access or policy conditions where supported | Often bound to the resource it runs on |
| Revocation | Delete or roll the key; breaks every user of that key | Disable account or delete credential | Change the binding; tokens expire quickly |
| Main OWASP NHI risks | NHI2 Secret Leakage, NHI7 Long-Lived Secrets, NHI9 NHI Reuse | NHI5 Overprivileged NHI, NHI7, NHI10 Human Use of NHI | NHI5 Overprivileged NHI, NHI6 Insecure Cloud Deployment Configurations |
Risks of each
API key risks
- Bearer use from anywhere: whoever has the string can use it, unless the provider enforces network or application restrictions. Leaks in code and files map to ATT&CK T1552.001 Credentials In Files.
- No principal, no authorisation: identifier keys cannot be checked against IAM roles. Treating them as authentication is the failure OWASP API2:2023 Broken Authentication warns about: API keys should be used for API client authentication, not user authentication.
- Shared keys: one key used by several systems means no attribution and a painful rotation, because every consumer breaks at once.
- Over-broad defaults: some providers create unrestricted keys unless you add restrictions. Google notes that keys created through the REST API are unrestricted unless an API restriction is specified, and states that unrestricted API keys are insecure.
- Vendor-side keys with customer reach: the BeyondTrust incident involved an infrastructure API key that could reset passwords of local application accounts on customer instances, showing how one key can carry tier-zero power.
Service account risks
- Standing privilege: service accounts tend to accumulate roles. Microsoft notes that Contributor is a common default Azure role and asks teams to apply the least possible permissions instead.
- Downloaded keys: a service account key file is a long-lived credential with the account's full roles. Google calls keys a security risk if not managed correctly and lets organisations disable key creation. See the Google Cloud Service Account Keys Security Guide.
- Human use: engineers log in as the service account to debug, which destroys attribution and often bypasses MFA (OWASP NHI10). See How to detect interactive logons by service accounts.
- Exclusions from policy: service accounts are often excluded from MFA and Conditional Access. See How to Find Accounts Excluded From MFA and Conditional Access.
- Orphans: the person who created the account leaves and nobody owns it. See How to assign owners to orphaned service accounts.
Which to use: decision table by integration type
| Scenario | Recommended | Why |
|---|---|---|
| Workload in the same cloud calling that cloud's APIs | Service account (or role, managed identity) attached to the resource | Credentials issued at runtime; no secret to store |
| Workload in another cloud, CI/CD or on-premises calling a cloud API | Service account through workload identity federation | Trades the platform's OIDC token for short-lived credentials; no key file |
| Kubernetes pod calling the cluster or a cloud API | Kubernetes service account with projected, short-lived tokens; federation for cloud access | Tokens expire and rotate; see the Kubernetes Service Account Token Guide |
| Integration with a SaaS that offers app installations or OAuth | App installation or OAuth client with a dedicated identity | Fine-grained permissions and short-lived tokens, not tied to an employee |
| Third-party API that only offers keys | Scoped API key per consuming system, held in a vault | No alternative; reduce blast radius with scope, network rules and rotation |
| Front-end or mobile app identifying itself for quota | Publishable or restricted identifier key | Designed to be exposed; never give it data or write access |
| Legacy Windows service on a domain | Group managed service account | Password managed by the domain; see the Group Managed Service Accounts (gMSA) Guide |
| AI agent acting on business data | Its own service identity with scoped, short-lived credentials | Attribution and revocation per agent; see the Agent Identity and Access Guide |
| Quick testing or a one-off script | Short-lived, narrowly scoped key or token with an expiry | Acceptable if it expires and never reaches production |
Small organisations can get most of the benefit by using the cloud provider's attached identities for everything they run and keeping a short, owned list of third-party keys in a single vault. Large organisations should make platform-issued service identities the default through policy (for example an organisation policy that blocks service account key creation), with an exception process for keys that records owner, scope and expiry.
How platforms implement the safer patterns
Examples from platform documentation, listed alphabetically. Each is a customer-side setting.
| Platform | Scoped or safer key option | Service identity option |
|---|---|---|
| GitHub | Fine-grained personal access tokens for testing and short-lived scripts | GitHub Apps: fine-grained permissions, chosen repositories, short-lived installation tokens, not dependent on a user |
| Google Cloud | API restrictions and application restrictions on API keys; Google recommends setting both | Attached service accounts, impersonation, Workload Identity Federation |
| Microsoft Entra | Certificates rather than client secrets for service principals | Managed identities and service principals, with sign-in log monitoring and Conditional Access location rules |
| Stripe | Restricted API keys with chosen permissions, access policies by IP, ASN or country, scheduled rotation and expiry | Managed API keys issued and rotated by supported hosting platforms; agent-tagged restricted keys with approval rules |
Security trade-offs
- Simplicity against control: a key is quick to issue and use; a service identity needs IAM design. The time saved is usually spent later in incident response and rotation.
- Portability against binding: a key works from anywhere, which is convenient and is also the problem. Platform-issued credentials only work where the platform can vouch for the caller.
- Blast radius: a scoped key per consumer can be safer than a shared service account with broad roles. Identity type alone does not decide risk; scope and lifetime do.
- Rotation cost: keys and stored service account secrets need rotation runbooks. Platform-issued credentials rotate themselves. See Credential Rotation at Scale.
Migrating from shared API keys to service identities
- Inventory keys and consumers. For each key record provider, scope, creation date, last use and every system that uses it. Request logs per key (where the provider has them) show the real consumers.
- Split shared keys. Issue one key per consuming system before anything else, so you gain attribution and can rotate one consumer at a time.
- Pick the target per integration. Use the decision table: attached identity, federation, app installation, or scoped key where nothing else exists.
- Create the service identity with least privilege. Start from the permissions the logs show the key actually used, not from the key's full rights.
- Run both in parallel. Switch a pilot instance to the new identity, watch error rates and audit logs, then roll out per environment.
- Disable, then delete. Disable the old key (or use the provider's rotation grace period, which Stripe sets at up to 7 days), watch for failed calls, then delete it. Rollback during the window is re-enabling the key.
- Block the old pattern. Add a guardrail: organisation policy against key creation, secret scanning in repositories, and a review gate for new keys.
Detection and measurement
Log key creation, use and deletion at each provider, and service account sign-ins, role changes and new credentials in your identity platform. Alert on a key or service account used from a new network or region, a service account signing in interactively, and new credentials added to an existing service account (ATT&CK T1098.001 Additional Cloud Credentials). Microsoft recommends monitoring service principal sign-ins in Entra sign-in logs. See the Service Account Behavioural Baselining Guide.
- Shared key count: keys used by more than one system, target zero.
- Platform-issued share: percentage of integrations using attached, federated or app-installation identities.
- Service account key count: downloaded service account keys in existence, trending down.
- Median key age: for keys that remain, against your rotation standard.
- Ownership coverage: keys and service accounts with a named owner, target 100 percent for anything privileged.
- Unrestricted keys: keys with no API scope or network rule, target zero.
Common failure patterns
- Using an identifier key as authentication. Treating a quota key as proof of who is calling, then exposing data behind it.
- Swapping a key for a service account key file. The integration moves to a "proper identity" but the credential is still a long-lived file, now with broader roles.
- One service account for many integrations. Convenient, unattributable and impossible to scope. Each integration needs its own identity.
- Personal tokens running production integrations. The integration breaks, or keeps working with too much access, when the person changes role or leaves. GitHub notes that an app installation keeps working when the installer leaves; a personal token does not.
- Keys that never expire in code. The Toyota T-Connect key exposure shows a key left valid in a public repository for almost five years.
- No restriction because "it is internal". Keys and service accounts without network rules can be used by anyone who copies them.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01, PR.AA-05 | Manage identities and credentials for services; least privilege access |
| NIST CSF 2.0 | DE.CM-03 | Monitor technology usage for adverse events, including key and service account use |
| NIST SP 800-53 Rev. 5 | IA-9, IA-5, IA-5(2) | Service identification and authentication; authenticator management; public key-based authentication |
| NIST SP 800-53 Rev. 5 | AC-2, AC-6, AU-6 | Account management, least privilege, audit review |
| CIS Controls v8.1 | Safeguard 5.5 | Inventory of service accounts |
| ISO/IEC 27001:2022 Annex A | A.5.17, A.5.18, A.8.5 | Authentication information, access rights, secure authentication |
| OWASP API Security Top 10 2023 | API2:2023 Broken Authentication | API keys for client authentication only |
| MITRE ATT&CK | T1552.001, T1078.004, T1528, T1098.001 | Credentials in files, cloud account abuse, token theft, added cloud credentials |
Practitioner checklist
- Classify every API key as identifier, account or scoped, and remove account-level keys where a scoped option exists.
- Give every integration its own identity or key; no sharing across systems.
- Default new integrations to platform-issued service identities (attached, federated or app installation).
- Block or gate creation of service account key files through policy.
- Apply API scope and network restrictions to every key that remains.
- Record an owner, purpose and expiry for every key and service account.
- Alert on interactive logons by service accounts and on new credentials added to them.
- Run secret scanning on repositories and pipelines (see the Git Secret Scanning Guide).
- Review service account permissions against actual use each quarter.
Standards and references
- OWASP: Non-Human Identities Top 10 2025
- OWASP: API Security Top 10 2023, API2 Broken Authentication
- NIST: SP 800-53 Rev. 5
- Google Cloud: Manage API keys
- Google Cloud: Service accounts overview
- Microsoft Learn: Securing service principals in Microsoft Entra ID
- GitHub Docs: Deciding when to build a GitHub App
- Stripe Docs: API keys
Related NHI Mgmt Group resources: API Key Management Guide, API Keys vs OAuth Tokens Guide, Non-Human Identity (NHI) Guide, Cloud Workload Identity Guide, How to Run an Access Review for Service Accounts.