---
"@context": https://schema.org
"@type": TechArticle
"@id": https://www.twilio.com/docs/usage/api-security-reference-guide/secrets-management#article
headline: Secrets management
description: Learn how to securely store and manage Twilio API credentials in your applications.
url: https://www.twilio.com/docs/usage/api-security-reference-guide/secrets-management
inLanguage: en
dateModified: 2026-10-30T15:44:40.000Z
author:
  "@type": Organization
  name: Twilio Developer Education Team
publisher:
  "@type": Organization
  name: Twilio
---

# Secrets management

To prevent credential compromise, you must keep your secrets secure. Twilio encrypts secrets at rest using *[Advanced Encryption Standard][] with 256-bit keys and [Galois/Counter Mode][]* (AES-256-GCM) cipher. Once Twilio issues credentials, you must protect them.

## Why secrets management matters

If you expose your Twilio credentials, an attacker might use them in one or more of the following ways:

* Sending unauthorized messages or making calls that impact your reputation or finances, such as [toll fraud][].
* Sending unauthorized messages or making calls that impact your reputation or finances, known. as [Toll fraud][]
* Engaging in unauthorized messaging or voice activity.
* Abusing your account and consuming your resources.
* Accessing your account data without permission.

## Secrets storage solutions

Store Twilio credentials in a dedicated secrets manager. Recommended solutions include:

* [AWS Secrets Manager][]: For deployments hosted in AWS.
* [Azure Key Vault][]: For deployments hosted in Microsoft Azure.
* [Google Cloud Secret Manager][]: For deployments hosted in Google Cloud Platform.
* Enterprise secrets-management platform that your organization approved.

If you don't have a dedicated secrets manager, use server-side environment variables or an operating-system keychain. These provide acceptable *minimum* safeguards for development and limited deployments. These alternatives shouldn't *replace* a managed secrets solution for production workloads.

## Best practices

To protect your Twilio credentials throughout their lifecycle, follow these practices:

* Never hardcode credentials in source code, configuration committed to version control, or client-side JavaScript.
* Never commit credentials to a Git repository, even temporarily.
* Don't store secrets in plain-text documents, tickets, chat messages, or shared notes.
* Don't share secrets with coworkers or third parties through informal channels. Trusted people may still use compromised devices or websites.
* Limit access to secrets using least privilege and *role-based access controls* (RBAC).
* Separate production credentials from development and test credentials.
* Rotate credentials on a regular cadence *and* after personnel, vendor, environment, or access changes.
* Monitor access to secrets and investigate unexpected retrieval or use.
* Remove secrets from logs, error messages, crash reports, and support bundles.
* Revoke and replace credentials immediately if exposure is suspected.

These practices support a [*zero-trust architecture* (ZTA)][zta]:

* Grant access only to what needs to be accessed.
* Grant access only to the identities that need it.
* Grant access only as long as needed.

## Common challenges and solutions

When you encounter one of these challenges, consider the offered solution:

| Challenge                             | Solution                                                                                                                                        |
| ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| Credentials for local development     | Use short-lived credentials with restricted scope, stored in local environment variables or a keychain, and never committed to version control. |
| Rotating credentials without downtime | Implement dual credentials during transition. Create new credential, deploy, test, and then remove old credential. Automate where possible.     |
| Third-party vendor API access         | Use [Restricted API Keys][] scoped to only the resources and permissions they need. Monitor their usage.                                        |
| Credentials leaked in logs            | Implement log redaction rules that prevent credentials from being stored. Identify sensitive fields with structured logging.                    |

## Next steps

Learn more about securing your Twilio integration:

* [Secure authentication][] methods and best practices
* [Incident response][] procedures for credential compromise
* [Defense-in-depth strategy][] for layered security

To learn more about fraud-prevention, see Twilio's [Quarterly Fraud Update][].

[AWS Secrets Manager]: https://aws.amazon.com/secrets-manager

[Azure Key Vault]: https://azure.microsoft.com/en-us/products/key-vault

[Google Cloud Secret Manager]: https://cloud.google.com/secret-manager/docs

[Secure authentication]: /docs/usage/api-security-reference-guide/secure-auth

[Incident response]: /docs/usage/api-security-reference-guide/incident-response

[Defense-in-depth strategy]: /docs/usage/api-security-reference-guide/defense-in-depth-strategy

[Quarterly Fraud Update]: https://www.twilio.com/en-us/blog/insights/best-practices/quarterly-fraud-update-june-2026#toc-nav-3

[Toll fraud]: /docs/verify/preventing-toll-fraud

[zta]: https://en.wikipedia.org/wiki/Zero_trust_architecture

[Restricted API Keys]: /docs/iam/api-keys/restricted-api-keys

[Galois/Counter Mode]: https://en.wikipedia.org/wiki/Galois/Counter_Mode

[Advanced Encryption Standard]: https://en.wikipedia.org/wiki/Advanced_Encryption_Standard