--- "@context": https://schema.org "@type": TechArticle "@id": https://www.twilio.com/docs/usage/api-security-reference-guide/incident-response#article headline: Incident response for credential exposure description: Learn about best practices for responding to Twilio credential exposure incidents. url: https://www.twilio.com/docs/usage/api-security-reference-guide/incident-response inLanguage: en dateModified: 2026-10-30T15:44:40.000Z author: "@type": Organization name: Twilio Developer Education Team publisher: "@type": Organization name: Twilio --- # Incident response for credential exposure Credential exposure derives from a serious security incident that requires immediate action. The faster you detect and respond to the incident, the smaller the window of exposure and the more you can limit unauthorized activity. A well-prepared incident response plan can reduce response time from hours to minutes. ## Prerequisites and preparation Before a credential exposure occurs, prepare your team and systems: * Establish an incident response team with defined roles and responsibilities. * Document who to contact during an incident (security team, ops, vendor management). * Set up monitoring and alerting systems for suspicious activity. * Test your incident response procedures quarterly. * Train team members on their roles and responsibilities. * Maintain access to credential management systems and Twilio account. * Keep a backup credential rotation process in case primary systems are compromised. ## Immediate response steps If a Twilio credential may have been exposed, follow these steps in order. Speed is critical—complete this entire process within the first hour: 1. **Revoke or rotate the affected credential immediately** in the Twilio Console. * Remove the compromised credential entirely or rotate to a new one. * For Auth Tokens, create a new Auth Token before disabling the old one. * For API keys, deactivate and create a replacement. 2. **Deploy the replacement credential** through your approved secrets-management process. * Update all applications and environments using the old credential. * Verify all deployed instances are using the new credential. * Monitor for errors indicating instances still using old credential. 3. **Review Twilio activity logs** for unauthorized access patterns. * Check usage reports for unexpected SMS, voice, or API calls. * Review authentication logs for failed login attempts or unusual timestamps. * Check messaging activity for unfamiliar sender IDs or recipients. * Review billing for unexpected charges or spike in usage. 4. **Check application and infrastructure logs** to determine exposure path. * Search application logs for the exposed credential value. * Check CI/CD systems and deployment logs. * Review cloud provider audit logs (CloudTrail, Activity Log, etc.). * Search container registries and image histories. * Check DNS and firewall logs for unauthorized access patterns. 5. **Add preventive controls** to stop recurrence. * Enable automated secret scanning in source code repositories. * Implement shorter token lifetimes (1 hour instead of 24 hours). * Use Restricted API Keys with narrower permissions. * Improve log redaction to prevent credential exposure in logs. * Enable MFA (multi-factor authentication) for credential access. 6. **Escalate suspected fraud** through proper channels. * Report to Twilio Support with incident details and timeline. * Report to your internal security and compliance teams. * Document the incident for audit and regulatory reporting. * If fraud occurred, report to financial fraud investigation team. ## Detection strategies Detecting credential compromise quickly is critical to limiting unauthorized activity. Implement these detection mechanisms: ### Automated secret scanning * Scan source code repositories for exposed credentials (GitHub secret scanning, [TruffleHog][], GitGuardian). * Monitor commit histories, even "deleted" commits. Credentials can remain in git history. * Scan Docker images and container registries. * Scan CI/CD logs and build artifacts. * Scan production logs and backups regularly. ### Monitoring and alerting Monitor Twilio API activity for patterns that indicate compromise: * **Geographic anomalies**: API requests from unexpected countries or regions. * **Rate spikes**: Sudden increase in API request volume (possible automated exploitation). * **New endpoints**: Access to API resources not previously accessed. * **New HTTP methods**: Unusual `DELETE` requests where only `GET` and `POST` are normal. * **Unusual timing**: API requests outside normal business hours. * **Failed authentication**: Sudden spike in 401/403 errors (possible credential guessing). ### Billing and usage alerts * Set up alerts for unexpected account charges. * Monitor SMS/voice volume for sudden increases. * Alert on unusual sender IDs or recipient patterns. * Compare current usage to historical baseline. ### Log aggregation and analysis * Centralize application, infrastructure, and API logs. * Use log analysis tools to detect unauthorized API calls. * Set up alerts for suspicious patterns. * Retain logs for at least 90 days (or per compliance requirements). ### Access reviews and audits * Conduct monthly reviews of who has access to production credentials. * Audit credential usage and rotation. * Document all credential access in an audit log. * Remove access for team members who no longer need it. ## Prevention: Reduce risk after incidents After an incident, implement preventive measures to reduce risk of future compromise: ### Credential design and lifecycle * Limit the scope and blast radius of leaked credentials with [Restricted API Keys][]. * Implement [short-lived tokens][] that expire without your intervention (one hour or less, where practical). * Store all credentials in a [secrets manager][secrets] with encryption and access control. * Separate credentials by environment (development, staging, production). * Separate credentials by application and function. * Automate credential rotation at a minimum of an annual basis. ### Infrastructure and access control * Implement least-privilege access to credential storage systems. * Use *role-based access control* (RBAC) to limit who can access credentials. * Enable MFA for systems storing or accessing credentials. * Audit and log all credential access. * Use network segmentation to restrict access to credential systems. ### Monitoring and detection * Enable secret scanning in all repositories. * Implement application-level rate limiting and anomaly detection. * Set up billing and usage alerts. * Centralize and monitor logs for suspicious patterns. * Conduct security reviews and testing quarterly. ## Common response mistakes These mistakes can delay response and increase damage: | Mistake | Consequence | Correct approach | | ---------------------------------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------------- | | Waiting to investigate before rotating credentials | Attacker continues unauthorized access during investigation. | Rotate immediately, then investigate while new credential is in place. | | Rotating only the primary credential, not all copies | Attacker may have cached old credential; compromise continues. | Identify all systems using the credential and update all simultaneously. | | Failing to verify new credential is deployed | Systems remain on old credential; incident continues. | Monitor application errors and verify all instances are using new credential. | | Not investigating the root cause | Same vulnerability remains; re-compromise happens immediately. | Determine how credential leaked and fix the root cause. | ## Next steps Prepare for and respond to incidents effectively: * [Defense-in-depth strategy][]: Comprehensive prevention approach * [Secrets management][secrets]: Secure credential storage and rotation * [Secure authentication][]: Short-lived tokens and restricted access * [Monitoring and alerting][]: Detecting unusual activity * [Authentication anti-patterns][]: Mistakes to avoid * Consult your organization's security and compliance teams for incident response procedures [Authentication anti-patterns]: /docs/usage/api-security-reference-guide/auth-anti-patterns [Defense-in-depth strategy]: /docs/usage/api-security-reference-guide/defense-in-depth-strategy [Monitoring and alerting]: /docs/usage/api-security-reference-guide/https-interactions-methods [Restricted API Keys]: /docs/usage/api-security-reference-guide/secure-auth [secrets]: /docs/usage/api-security-reference-guide/secrets-management [Secure authentication]: /docs/usage/api-security-reference-guide/secure-auth [short-lived tokens]: /docs/usage/api-security-reference-guide/secure-auth [trufflehog]: https://github.com/trufflesecurity/trufflehog