Non-Human Identity Governance: Managing Service Accounts, API Keys, and Secrets at Scale

Start with four discovery channels run in parallel: source code repositories, cloud IAM, secrets vaults, and network traffic.

For repositories, run TruffleHog against every repo in your GitHub organization: trufflehog github --org=yourorg --only-verified --json > findings.json. The --only-verified flag reduces noise by testing whether detected credentials are still active before reporting them. For GitHub's native secret scanning, enable it at the organization level under Security and Analysis settings. GitHub will alert on pushes containing known secret patterns for over 200 providers and, where the provider supports it, automatically revoke the secret.

For AWS, generate the IAM Credential Report from the console or CLI: aws iam generate-credential-report && aws iam get-credential-report --query Content --output text | base64 -d > cred-report.csv. The report lists every IAM user, their access key ages, last used timestamps, and MFA status. Filter for access keys unused for more than 90 days and keys older than 365 days. These are your first rotation targets.

For Azure, use the Service Principal activity report in Entra. Cross-reference service principals against the resources they have access to using the Azure Resource Graph: resources | where type == 'microsoft.web/sites' | join kind=leftouter (authorizationresources | where type == 'microsoft.authorization/roleassignments') on subscriptionId.

For network traffic, analyze NetFlow or VPC Flow Logs for outbound connections from internal services to external API endpoints. Source IPs that are servers rather than workstations making API calls are likely NHIs that do not appear in your IAM discovery.

An NHI without an owner is an NHI that will never be rotated or deprovisioned. The ownership model needs to be simple enough that engineers will actually use it.

Assign ownership at the team level, not the individual level. Individuals leave. Teams persist. Tag every NHI with two metadata fields: owner-team (the Slack team handle or organizational unit) and purpose (a one-line description of what this credential is used for and which system it authenticates to).

For AWS IAM, use resource tags on IAM users and roles. For GitHub deploy tokens, use the Notes field. For Azure service principals, use the Description field and custom attribute extensions.

Build a lightweight NHI registry as a CSV or database table with columns: credential-id, credential-type, owner-team, purpose, last-rotated, expiry-date, rotation-method (manual, automated), last-used, and status (active, dormant, deprecated). Update this registry as part of your quarterly access review process.

Dormant credentials are those unused for 90-plus days. Establish a policy: dormant credentials are disabled automatically after 90 days of inactivity and deleted after 180 days unless an owner explicitly renews them. This creates forcing functions for owners to maintain their inventory.

Manual rotation does not scale. For any credential that authenticates to a system that supports programmatic updates, automate rotation.

AWS Secrets Manager supports native rotation for RDS, Redshift, DocumentDB, and custom Lambda-backed rotation for any other secret. Enable rotation on a schedule: aws secretsmanager rotate-secret --secret-id MySecret --rotation-rules AutomaticallyAfterDays=30. The rotation Lambda generates a new credential, tests it, updates the secret, and deprecates the old credential in sequence.

HashiCorp Vault dynamic secrets eliminate the rotation problem entirely by generating short-lived credentials on demand. For database secrets, configure a database secrets engine: vault write database/roles/my-role db_name=my-database creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}'; GRANT SELECT ON mydb.* TO '{{name}}'@'%';" default_ttl=1h max_ttl=24h. Each application that calls vault read database/creds/my-role gets a unique credential that expires automatically.

Azure Key Vault supports certificate and key rotation with Event Grid triggers. For service principal client secrets, build a rotation pipeline: an Azure Function triggered by a Key Vault expiry event that generates a new client secret, updates the Key Vault secret, and updates the application configuration referencing it. Store the rotation pipeline code in your infrastructure repository so it is reviewed and versioned.

For credentials that cannot be automatically rotated (third-party APIs with manual key generation), implement rotation reminders: tag the credential with a rotation-due date, query your registry weekly, and send Slack alerts to the owner-team 14 days before expiry.

Rotating credentials stops stale-credential attacks. Detecting anomalous usage of active credentials catches in-progress abuse.

For AWS, CloudTrail provides the event source. Key detection patterns: (1) API calls from unexpected source IPs for service accounts that normally call from specific VPC CIDR ranges. (2) Calls to IAM, STS, or organization APIs from non-human identities that should only be calling application-layer services. (3) Unusually high call volumes that may indicate credential stuffing or data exfiltration.

Sentinel KQL for AWS credential anomaly: AWSCloudTrail | where TimeGenerated > ago(1h) | where UserIdentityType == "IAMUser" | where UserIdentityUserName startswith "svc-" | where SourceIpAddress !startswith "10." and SourceIpAddress !startswith "172." | project TimeGenerated, UserIdentityUserName, EventName, SourceIpAddress, RequestParameters.

For Azure service principals, use Entra audit logs: AuditLogs | where TimeGenerated > ago(1h) | where InitiatedBy.app.displayName !startswith "" | where OperationName in ("Add member to role", "Update application", "Add owner to service principal") | where Result == "success".

For GitHub, monitor for personal access tokens and deploy keys used from IP addresses that do not match your CI/CD runner ranges. GitHub audit log API provides token-level detail that can be forwarded to your SIEM via webhook.

Enterprise PAM solutions like CyberArk and BeyondTrust are effective but cost-prohibitive for many organizations. The following stack provides comparable coverage at near-zero incremental cost for organizations already in AWS, Azure, or GitHub.

For secret storage: AWS Secrets Manager (included in AWS, $0.40/secret/month) or Azure Key Vault (included in most Azure subscription tiers). For self-hosted or multi-cloud, HashiCorp Vault Community Edition is free and supports all major cloud providers.

For discovery: TruffleHog (open source), GitHub Secret Scanning (included in GitHub Advanced Security, free for public repos), AWS IAM Credential Report (free, API-based), Semgrep with secrets rules (free tier available).

For rotation: AWS Secrets Manager rotation Lambdas (AWS-managed templates available for common databases), Vault dynamic secrets engines, Azure Key Vault rotation policies.

For inventory: A Git-tracked CSV file or a simple database table is sufficient for most organizations under 5,000 NHIs. For larger inventories, tools like Clutch (open source internal platform) or Airtable (low-code) can provide a UI over the registry without requiring a dedicated PAM product.