68% of Cloud Breaches? The Non-Human Identity Crisis is Real
Hey everyone,
I just came across this webinar regarding 'Ghost Identities' and the statistics are honestly terrifying. We spend so much time focusing on phishing simulations and complex password policies, but apparently, 68% of cloud breaches in 2024 were driven by compromised service accounts and forgotten API keys.
The stat that really got me was the ratio of identities: for every human employee, there are 40 to 50 non-human identities (service accounts, bots, OAuth grants). When projects die or people leave, these credentials almost always stay active. It’s the ultimate 'set it and forget it' failure mode.
I’ve been trying to audit our Azure environment for stale service principals. It’s messy. Here is a quick PowerShell snippet I’m using to identify App Registrations that haven’t had a login in the last 90 days:
$Date = (Get-Date).AddDays(-90)
Get-AzureADServicePrincipal -All $true | Get-AzureADAppServicePrincipalAssignedTo | ForEach-Object {
$sp = $_
$lastLogon = Get-AzureADAuditSignInLog -Filter "appId eq '$($sp.AppId)'" -Top 1 | Sort-Object CreatedDateTime -Descending | Select-Object -ExpandProperty CreatedDateTime
if ($lastLogon -lt $Date) {
Write-Warning "Stale App Found: $($sp.DisplayName) | Last Logon: $lastLogon"
}
}
Has anyone successfully implemented automated lifecycle management for these non-human identities? I’m looking at tools like Teleport or dedicated CSPM solutions, but I'm curious what works in the real world.
How are you handling the cleanup of these 'ghost' credentials?
Great snippet. We struggled with this in AWS until we started enforcing strict conditional access policies on IAM roles.
We also use a scheduled Lambda function that runs nightly to tag any role or user that hasn't utilized an API key in 60 days with Status: Stale. If they hit 90 days, a second function automatically disables the keys. It forces developers to rotate or explicitly re-enable them, which keeps the inventory clean.
From a Red Team perspective, these are the gold mine. We often find old CI/CD pipelines or deployment scripts with hardcoded IAM keys that have 'AdministratorAccess' because 'it was just for that one migration project' three years ago.
I strongly suggest looking at Secret Scanning tools in your repos (TruffleHog or Gitleaks) combined with your cloud audit logs. If you find a key in a public repo, assume it's already being used by someone else.
The 40:1 ratio sounds about right. We moved away from long-lived static keys almost entirely for our internal services.
We implemented Workload Identity Federation in GCP and IRSA in EKS. It lets the K8s pods assume IAM roles via OIDC tokens. It removes the need to manage static secrets for the most part, though you still have to manage the trust policies strictly. It's not a silver bullet, but it reduces the attack surface significantly.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access