Service Accounts: Secure Integration Credentials

Every integration needs credentials to reach the systems it connects. Too often, those credentials belong to a person: an administrator's login, an API key created under someone's account or a shared password stored in a spreadsheet. When that person leaves, changes role or resets their password, the integration breaks, and in the meantime it runs with far more access than it needs. Service accounts solve this. A service account is a non-personal identity created for a specific integration or automation, with only the permissions that job requires. This guide explains how to set up service accounts, limit their access, store their secrets safely, rotate credentials and audit what they do.

What service accounts are

A service account is an account used by software rather than a person. Depending on the platform, it may be called an integration user, API user, application account or service principal. It authenticates with credentials such as API keys, OAuth client credentials, tokens or certificates, and it appears in logs under its own name.

Using a dedicated identity for each integration makes it clear which system did what, and it separates the integration's lifecycle from any employee's. Staff can join, move and leave without breaking the connections the business depends on.

Problems with personal credentials

Integrations running under personal accounts cause predictable problems:

• They break when the person leaves, is deactivated or changes password
• They usually have the person's full access, not just what the integration needs
• Logs show the person's name for automated actions, confusing audits
• Multi-factor authentication on personal accounts may block automated logins
• Credentials are often shared informally and hard to track

One service account per integration

Create a separate service account for each integration or automation, rather than one shared account for everything. This allows:

• Permissions tailored to each integration
• Clear audit trails showing which integration made each change
• Revoking or rotating one integration's access without affecting others
• Monitoring usage per integration, including API limits

Name accounts clearly, for example by system and purpose, and record an owner for each. The owner is responsible for keeping permissions appropriate, rotating credentials on time and retiring the account when the integration ends.

Apply least privilege

Give each service account only the access it needs. The OWASP Authorization Cheat Sheet recommends enforcing least privileges and denying by default (OWASP Authorization Cheat Sheet). In practice:

• Grant access only to the modules, objects or data the integration uses
• Prefer read-only access where writing is not needed
• Restrict sensitive operations, such as deletions or exports, unless essential
• Use scoped API permissions or OAuth scopes where available
• Review permissions when the integration changes

Our guide to role-based access control explains how to design roles and permissions that can also be applied to service accounts.

Store secrets safely

Service account credentials are secrets and must be protected. The OWASP Secrets Management Cheat Sheet notes that many organisations have secrets hardcoded in source code and configuration files, and recommends centralising secrets management, applying least privilege to who can access secrets and auditing access (OWASP Secrets Management Cheat Sheet). Practical steps:

• Store credentials in a secrets manager or the integration platform's secure credential store
• Never put secrets in code repositories, spreadsheets, chat messages or emails
• Limit who can view or change each secret
• Log access to secrets

Rotate credentials

Credentials should be changed periodically and immediately when there is any risk they have been exposed, or when someone with access leaves. Plan rotation so it does not break integrations:

• Know where each credential is used
• Create the new credential before revoking the old one where the platform allows
• Update the integration, test it, then revoke the old credential
• Automate rotation where the platform supports it

Worked example: a service accounts register

The table below shows a hypothetical register for a mid-sized company. Systems, scopes and dates are illustrative.

Service accountUsed bySystemAccess grantedCredential typeStored inOwnerRotationsvc-crm-webformsWebsite form integrationCRMCreate and update leads onlyOAuth clientSecrets managerMarketing operationsEvery 6 monthssvc-crm-finance-syncFinance syncCRMRead accounts and deals; update invoice fieldsOAuth clientIntegration platform vaultFinance systemsEvery 6 monthssvc-erp-ordersOrder integrationERPCreate sales orders; read stockAPI keySecrets managerOperationsEvery 3 monthssvc-reporting-exportNightly reporting exportCRMRead-only on selected modulesOAuth clientSecrets managerData teamEvery 6 months

The register makes it easy to see who owns each account, what it can do and when its credentials are due for rotation.

Handle multi-factor authentication

Personal accounts should use multi-factor authentication. Service accounts usually cannot complete interactive prompts, so use authentication methods designed for applications, such as OAuth client credentials, signed tokens or certificates, rather than disabling security on a user account. Where a platform only supports user accounts for integrations, restrict that account tightly and monitor it closely.

Audit what service accounts do

Because service accounts often act at scale, their activity deserves attention:

• Make sure their actions appear in audit logs under their own names
• Monitor for unusual activity, such as large exports or access outside normal patterns
• Alert on failed authentication attempts
• Review the register and permissions periodically

Our guide to Zoho CRM integration security covers audit and permission practices for CRM integrations specifically.

Plan for emergencies

Decide in advance what happens if a service account's credentials are leaked or misused. Responders should know how to disable the account or revoke its credentials quickly, which integrations will stop as a result and who must be told. Keep this information in the register or the integration's runbook. Being able to cut off one integration's access cleanly, without affecting others, is one of the main benefits of having separate service accounts.

Remove unused service accounts

When an integration is retired, disable its service account, revoke its credentials and remove it from the register. Unused accounts with live credentials are an easy target, and nobody is watching them closely.

Include service accounts in governance

Add service account creation to your automation governance process: who can request one, who approves it, what information must be recorded and how often it is reviewed. This keeps the register complete as new integrations are added.

Frequently Asked Questions

What is a service account?

It is a non-personal account used by an integration or automation, with its own credentials and permissions, so automated actions are separate from any employee's account.

Why not use an administrator account for integrations?

It gives the integration far more access than it needs, breaks when the administrator leaves or changes password, and makes audit logs misleading.

Where should service account credentials be stored?

In a secrets manager or a secure credential store, with restricted access and logging, never in code, spreadsheets, chat or email.

How often should service account credentials be rotated?

On a regular schedule set by your security policy, and immediately if exposure is suspected or someone with access leaves.

Secure every integration's access

We set up service accounts, scoped permissions, secure credential storage and rotation for your integrations. See our AI automation solutions, or talk to us about service accounts.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.