The Silent Threat: Orphaned API Keys & Service Accounts
Orphaned API keys and service accounts are forgotten credentials that remain active in your cloud environment long after their purpose is gone. They are the leading cause of cloud breaches in India — with 68% of 2024 incidents traced to unmanaged non-human identities. This guide explains how attackers exploit them and exactly what Indian SMBs must do to eliminate the risk.
When I was architecting security for Fortune 500 companies, we would conduct annual audits of service accounts and API keys. Almost every time, we would find dozens — sometimes hundreds — of forgotten credentials lying dormant in production environments. No one remembered creating them. No one was monitoring them. And most importantly, no one was rotating them.
In 2024, this pattern became catastrophic. Compromised service accounts and forgotten API keys were behind 68% of all cloud breaches — not phishing attacks, not weak passwords, but unmanaged non-human identities that organizations had simply abandoned.
For every single employee in your organization, there are 40 to 50 automated credentials: service accounts, API tokens, AI agent connections, OAuth grants, and more. When projects end or employees leave, most of these credentials are never deprovisioned. They sit in your environment, unchanged, unmonitored, and vulnerable.
Originally reported by The Hacker News.
What Happened: The Anatomy of Credential Abandonment
The threat is not new, but its scale is unprecedented. Here is the pattern across Indian cloud deployments:
The Lifecycle of an Orphaned Credential:
- Creation — A developer spins up a service account to connect a microservice to a database. An API key is generated for a third-party integration. An OAuth token is issued for a CI/CD pipeline.
- Abandonment — The project gets deprecated. The employee moves teams. The integration gets replaced. But the credential remains — still valid, still active, still accessible.
- Exposure — The credential gets accidentally committed to a GitHub repository. It is embedded in logs. It is hardcoded in a config file. It leaks through a supply chain compromise.
- Exploitation — An attacker finds it using automated scanning tools. They use it to access databases, APIs, or cloud infrastructure.
- Breach — By the time you discover the compromise, the attacker has already exfiltrated data, planted backdoors, or encrypted your systems.
Why Do Orphaned API Keys Put Indian Businesses at Risk?
Regulatory Pressure
India's Digital Personal Data Protection (DPDP) Act requires organizations to demonstrate that they have implemented reasonable security measures. If a breach happens because of an orphaned credential, regulators will ask: why was this credential not monitored? Why was it not rotated? You will struggle to prove compliance.
CERT-In's 6-Hour Mandate
Under CERT-In guidelines, you must notify the Indian Computer Emergency Response Team within 6 hours of discovering a breach. If you do not know what credentials you have, how will you know what was compromised? How will you contain the incident in time?
Cloud Adoption Without Security Infrastructure
Many Indian SMBs are migrating to AWS, GCP, or Azure without the security practices that enterprises use. They are creating service accounts in AWS IAM, API keys in GCP, and managed identities in Azure — but not implementing identity governance. The result: orphaned credential sprawl.
Third-Party Risk
When you integrate with vendors (payment gateways, SMS providers, analytics platforms), you generate API keys. Many SMBs never revoke these keys, even after the relationship ends. A compromised vendor means your credentials are exposed.
How Do Attackers Find and Exploit Orphaned Credentials?
graph TD
A[Attacker Searches GitHub] -->|Finds API key in commit history| B[Validates Credential]
B -->|Tests against cloud APIs| C{Credential Active?}
C -->|Yes| D[Gains Cloud Access]
C -->|No| E[Move to Next Target]
D -->|Enumerates permissions| F[Lateral Movement]
F -->|Accesses databases and storage| G[Data Exfiltration]
G -->|Covers tracks| H[Breach Detected Too Late]
style A fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
style B fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
style C fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
style D fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
style E fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0
style F fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
style G fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0
style H fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0Where Orphaned Credentials Hide
Git Repositories (Most Common) — Developers accidentally commit credentials to GitHub, GitLab, or Bitbucket. Even if you delete the file later, the credential remains in commit history forever. Automated scanners can find these in seconds.
Environment Variables and Config Files — Service accounts and API keys are often stored in .env files (accidentally committed), config.yaml, Docker images (baked into image layers), or CloudFormation and Terraform files.
Logs and Monitoring Systems — If a credential is used in a request, it might appear in logs. Anyone with log access — developers, contractors, ex-employees — can extract credentials.
Backup and Disaster Recovery Systems — Old database backups, VM snapshots, and RDS backups often contain credentials embedded in application code or configuration files.
Dark Web and Credential Markets — Credentials leaked from one company are often resold on dark web marketplaces. Attackers buy lists of API keys and test them against thousands of targets automatically.
The Attack Sequence: Why Old Credentials Are Dangerous
sequenceDiagram
participant Attacker
participant API as Cloud API
participant App as Your Application
participant DB as Database
Attacker->>API: Uses stolen API key
API->>API: No rate limiting on old key
API->>App: Request granted
App->>DB: Attacker queries customer data
DB->>App: Returns thousands of records
App->>Attacker: Data exfiltrated
Note over Attacker: 3 days pass before detectionOld credentials often bypass modern security controls because they predate your current policies. They do not use MFA. They are not subject to anomaly detection. If you never set an expiration date, they are valid forever.
According to Microsoft Security research, credential-based attacks account for over 80% of cloud breaches — and orphaned identities are the easiest entry point because they lack any active monitoring.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanHow to Protect Your Business
| Protection Layer | Action | Difficulty | Timeline |
|---|---|---|---|
| Discovery | Audit all service accounts and API keys | Medium | 1-2 weeks |
| Classification | Tag each credential with owner, purpose, creation date | Medium | 2-3 weeks |
| Deprovisioning | Delete credentials that are unused or orphaned | Easy | 1 week |
| Rotation | Set automatic rotation for active credentials (90 days) | Hard | 2-4 weeks |
| Monitoring | Alert on unusual credential usage patterns | Hard | Ongoing |
| Governance | Enforce credential lifecycle policies | Hard | 1-2 months |
Step 1: Discover All Non-Human Identities
For AWS:
# List all IAM users including service accounts
aws iam list-users --query 'Users[*].[UserName,CreateDate]' --output table
# Generate credential report
aws iam get-credential-report
# Check last used date for an access key
aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLEFor GCP:
# List all service accounts
gcloud iam service-accounts list
# Check key creation and expiry dates
gcloud iam service-accounts keys list --iam-account=my-sa@my-project.iam.gserviceaccount.com --format='table(name,validAfterTime,validBeforeTime)'For Azure:
# List all service principals
az ad sp list --output table
# List credentials for a service principal
az ad sp credential list --id 12345678-1234-1234-1234-123456789012Step 2: Identify Orphaned Credentials
A credential is orphaned if it has not been used in 90 days, has no documented owner, has no documented purpose, or has not been rotated in over 2 years.
Step 3: Delete or Rotate
# AWS: Delete an unused access key
aws iam delete-access-key --user-name myuser --access-key-id AKIAIOSFODNN7EXAMPLE
# GCP: Delete a service account key
gcloud iam service-accounts keys delete KEY_ID --iam-account=my-sa@my-project.iam.gserviceaccount.comStep 4: Implement Automatic Rotation
Use AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault to enforce automatic rotation every 30-90 days. Manual rotation is reliable only with automation behind it.
Step 5: Monitor and Alert
Set up alerts for credential usage from unusual IP addresses, bulk data downloads using old credentials, failed authentication attempts indicating brute-force testing, and credential creation without documented ownership.
git-secrets or truffleHog — many Indian SMBs discover years-old exposed keys this way.If you want to understand the broader attack surface that includes your APIs, read our guide on how VAPT scanning works for Indian SMBs — orphaned credentials are one of the top findings our automated scans surface.
You should also review how CERT-In compliance requirements affect your security posture — the 6-hour breach notification rule makes credential governance non-negotiable.
Frequently Asked Questions
Q: How many orphaned credentials does a typical Indian SMB have?
A: Based on industry data, organizations with 50 employees typically have 200-400 non-human identities. In my experience reviewing Indian SMB cloud accounts, 30-50% of these are orphaned — never used after initial creation, or abandoned after project completion. That is a large, silent attack surface.
Q: Is an API key that has never been used still dangerous?
A: Yes. An unused API key can still be found in commit history, config files, or logs. If it is valid, an attacker can use it regardless of whether you have used it yourself. Delete all credentials you cannot explain or justify.
Q: How does the DPDP Act change our liability for orphaned credentials?
A: The DPDP Act's "reasonable security" requirement means you are expected to have credential governance processes. If a breach occurs through an orphaned credential and your audit shows you had no processes to discover or deprovision such credentials, regulators will treat that as negligence — increasing both financial penalty exposure and reputational risk.
Q: We use a third-party SaaS tool that we cancelled last year. Should we revoke those API keys?
A: Immediately, yes. Any credentials issued to a vendor or SaaS tool should be revoked when the relationship ends. This is especially important for tools that had access to customer data, payment systems, or internal APIs. Check your cloud provider's audit logs to see if those credentials have been used recently.
Q: What is the single highest-impact action we can take today?
A: Run a credential report from your cloud provider (AWS IAM credential report, GCP service account audit) and delete all credentials not used in the last 90 days. This single action eliminates the majority of your orphaned credential risk.
How Bachao.AI by Dhisattva AI Pvt Ltd Detects This
Orphaned credentials are exactly the kind of silent, persistent risk that our platform is designed to surface.
Our API Security module scans your cloud infrastructure for orphaned service accounts, unused API keys, and credentials without rotation policies. It integrates with AWS IAM, GCP Service Accounts, and Azure Managed Identities to give you a complete inventory.
Our VAPT Scan includes credential discovery in your codebase, Git repositories, and cloud environments — surfacing what automated tools leave behind.
Our Dark Web Monitoring watches for your API keys and service account credentials being sold on the dark web or leaked in public repositories.
Our Incident Response team (24/7 available) helps you contain breaches caused by compromised credentials and notifies CERT-In within the 6-hour mandate.
Dhisattva AI Pvt Ltd, the company behind Bachao.AI, is a DPIIT Recognized Startup building India's most accessible automated VAPT platform.
The Path Forward
Orphaned credentials are not a technical problem you can ignore — they are a compliance and business continuity risk. Under the DPDP Act, you are required to maintain reasonable security. Under CERT-In guidelines, you must detect and respond to breaches within 6 hours. You cannot do either if you do not know what credentials you have.
The organizations that avoid breaches are not the ones with the most advanced tools. They are the ones with visibility and governance — they know what credentials exist, who owns them, when they were last used, and they have automated processes to clean up what they do not need.
Start today:
- Run a credential audit using the AWS/GCP/Azure commands above
- Delete all credentials not used in 90 days
- Set up automatic rotation for active credentials
- Enable monitoring and alerts for unusual credential usage
- Book a free VAPT Scan to surface what you might have missed
Bachao.AI by Dhisattva AI Pvt Ltd — discover and eliminate your orphaned credential risk before attackers find it first.
Written by Shouvik Mukherjee, Founder at Bachao.AI (Dhisattva AI Pvt Ltd, DPIIT Recognized Startup). Follow on LinkedIn for daily cybersecurity insights for Indian businesses.