NHI Kill Chain: Unattributed Key — 3,400 Secrets and Nobody Knows Who Made Them

3,400 Secrets. Owners Known for 40%.

Early 2026. A 500-person enterprise SaaS company. Eight years old. Three acquisitions, five organizational restructurings. The service was running reliably, revenue was growing steadily. From the outside, it looked like a healthy scale-up.

A new CISO started. The previous CISO had left abruptly for health reasons six months earlier, and the seat had been empty since. The new CISO's first directive was a full security posture assessment.

"Tell me how many NHI credentials exist in this organization."

A four-person security team spent two weeks on the audit. AWS IAM, GitHub, Slack, CI/CD pipelines, cloud services, SaaS integrations. The results surprised even them.

3,400 active NHI credentials. API keys, service accounts, bot tokens, IAM access keys, integration tokens. That worked out to roughly 6.8 NHI credentials per employee.

The number alone was staggering. But the real problem came next.

Credentials with a clearly identified owner: approximately 40% (1,360). The remaining 60% (2,040) had no identifiable creator, no documented purpose, and no assigned maintainer. Owner unknown.

The 2,040 fell into recognizable patterns, each one a different flavor of the same underlying problem: the link between credential and human had been severed.

Creator email addresses tied to deactivated accounts, former employees whose identity could be guessed but whose responsibilities had never been reassigned. When the security team tried to trace these credentials back, they found departure dates spanning three years. Some belonged to engineers who had left during the first acquisition. Others to contractors whose engagement had ended without a formal offboarding process. The credentials outlived every one of them.

Shared service accounts named terraform-deploy, ci-bot, monitoring-svc, created under no individual's name, with no documentation of which team managed them. These had been provisioned by someone, at some point, for some reason. But "someone" was no longer identifiable. The Slack channel where the service account was originally discussed had been archived. The Confluence page documenting the integration had been deleted during a workspace cleanup. The institutional memory was gone.

Credentials inherited from the three acquisitions, systems where no one in the current organization understood the creation context. The second acquisition, two years earlier, had brought in an entire microservices platform with its own set of API keys, service accounts, and integration tokens. The technical lead from the acquired company had stayed for six months during the transition period and then left. With him went the last person who understood why those credentials existed.

API keys created four or more years ago whose maintainer had changed hands three times, the current team lead's response was invariably, "I didn't create that. I inherited it from the previous lead, who inherited it from someone before that."

The CISO reviewed the report and ordered a cleanup. Priority one. The security team sat down to plan the effort, and realized they couldn't start. Of those 2,040 credentials, there was no way to determine which ones were still required for production, which ones could be safely retired, and which ones might bring critical systems down if revoked. Delete the wrong one and production breaks. Leave them all running and the attack surface keeps growing. Investigate each one manually and you're looking at months of work.

Credentials that can't be revoked, can't be rotated, and have no one to take responsibility for them. Orphaned credentials with no path home. This is the Unattributed Key.

Why This Key Is Dangerous

The Unattributed Key is the most structural of all NHI credential risk types. Unlike a Public Key (exposed through a leak) or a Ghost Key (orphaned by an employee's departure), the Unattributed Key doesn't result from a single event. It accumulates naturally as an organization grows. This isn't an incident. It's entropy.

The root cause is the absence of ownership tagging at creation. Most organizations have no policy requiring an explicit owner tag when an NHI credential is created. When an AWS IAM access key is provisioned, the "responsible owner" field isn't mandatory. When a GitHub Personal Access Token is generated, there's no workflow that captures "the team that manages this token" as metadata. Slack bot tokens, Datadog API keys, CI/CD service accounts, all the same. Creation is easy, tagging is optional, and most people skip it.

Organizational entropy accelerates the problem. Even when ownership is clear at creation, it erodes over time. The maintainer transfers to a different team. The team is dissolved. The project is terminated. An acquisition brings in an entirely new system. A reorganization shuffles reporting lines. Through every one of these changes, the credential remains active. People change, teams disappear, projects end, but credentials are never decommissioned.

Mergers and acquisitions are the most powerful generators of Unattributed Keys. When an acquired company's infrastructure and services are integrated, few organizations conduct a full NHI credential audit. The default posture is "the system is running, don't touch it." The result is that the acquired company's credentials persist in the acquiring company's infrastructure with no ownership mapping, no creation context, and no one who understands why they exist. A single acquisition can introduce hundreds of Unattributed Keys overnight.

These three forces compound. The older the organization, the larger its headcount, and the more acquisitions it has made, the higher the Unattributed Key ratio climbs. An early-stage startup might have fewer than 10% Unattributed. After five years, it's 40%. After eight years and three acquisitions, it's 60% or more. This isn't a failure of the security team. It's the structural outcome of growing an organization without an ownership tagging system for NHI credentials.

Kill Chain, How an Unattributed Key Becomes an Active Breach

The Unattributed Key kill chain is distinct from other NHI risk types. It doesn't begin with an external exposure or a single precipitating event. It begins with a governance deficit that accumulates over years. The attacker doesn't need to actively search for the vulnerability, the organization's structural weakness exposes it.

Stage 1: Ownership Gap at Creation

Credentials are created without ownership tagging. Service accounts are provisioned under a vague "team-shared" ownership model. API keys are generated quickly at project kickoff. Integration tokens are created as a natural part of system configuration. All of these come into existence without an explicit, accountable owner. Among organizations using AWS IAM, those that enforce an Owner tag on every service account are a small minority. Most don't even populate the Description field.

Stage 2: Organizational Entropy

Time passes. The person who created the credential leaves the company. The team that managed it is restructured. An acquisition brings in new systems. A project is decommissioned, but its infrastructure survives. With each of these events, one more layer of context, why the credential was created, where it's used, who is responsible for it, disappears. For a credential that's three years old, the probability that anyone in the organization fully understands its purpose approaches zero.

Stage 3: Governance Paralysis

When the owner is unknown, decommissioning decisions become impossible. "Can we delete this key?" has no one to answer it. The key might be running production workloads. Or it might not. Finding out requires manually tracing usage logs, identifying dependent systems, disabling the key in a staging environment, and observing the impact. Hours to days per credential. For 2,040 credentials, this is operationally infeasible. The conclusion is always the same: "Leave it for now." Indefinite neglect begins.

Stage 4: Silent Accumulation

When neglect is the default response, the absolute count of Unattributed Keys grows continuously. New credentials are created daily. Existing Unattributed Keys are never cleaned up. A key created five years ago, a service account from a team that was dissolved three years ago, a token inherited from the last acquisition, all remain active, accumulating. The Unattributed percentage of total NHI credentials rises year over year. The attack surface expands every month without a single incident triggering it.

Stage 5: Undetectable Compromise

When an Unattributed Key is compromised, what happens? Standard security monitoring is owner-based. When anomalous access is detected, the alert goes to the credential's owner. The owner evaluates whether the activity is legitimate or malicious. But an Unattributed Key has no owner. There is no one to receive the alert. Even if the SIEM logs an anomalous pattern, there is no designated responder to review and act on it.

Consider the practical implications. An attacker obtains one of the 2,040 Unattributed Keys, perhaps through a credential dump, perhaps through lateral movement from another compromised system, perhaps through a supply chain compromise of a third-party integration. The attacker authenticates. The credential works. The API calls begin. If the credential has production-level permissions, and many service accounts do, because they were created at a time when the principle of least privilege was an aspiration, not a policy, the attacker now has access to production data, infrastructure, or both.

The security team's SIEM might flag the anomalous access pattern. But the alert routing table says: notify the credential owner. The owner field is empty. The alert either goes nowhere, or it goes to a generic queue that gets reviewed weekly. By the time anyone notices, the attacker has been inside for days.

From the attacker's perspective, this is the perfect blind spot: a credential that is neither detected when compromised nor responded to when flagged. The Unattributed Key is not just unmanaged, it is undefended.

Why Traditional Security Tools Miss It

The reason Unattributed Keys persist for years is that no tool in the standard security stack was designed to solve this problem.

IAM owner fields are optional. AWS IAM, GCP IAM, Azure AD, none of the major cloud providers' IAM systems require an owner tag when a service account is created. A Description field exists. Tags can be applied. But enforcement is not enabled by default. Ownership tagging is something each organization must define and enforce as a custom policy. Most don't.

CMDBs don't include NHI credentials. Traditional IT asset management systems (CMDBs) track servers, network equipment, and software licenses. NHI credentials, API keys, service accounts, bot tokens, are not classified as assets in most CMDBs. When the security team requests an "asset inventory," NHI credentials are absent. What isn't inventoried cannot be managed.

M&A security due diligence has a blind spot. Security due diligence during acquisitions typically focuses on network architecture, data classification, compliance posture, and vulnerability scanning. The question "How many NHI credentials does the acquired company have, and who owns each one?" rarely appears on the due diligence checklist. After the acquisition closes, the acquired company's credentials join the acquirer's infrastructure without ownership mapping.

Quarterly access reviews focus on human accounts. Access reviews required by SOX, SOC2, ISO 27001, and similar compliance frameworks have traditionally focused on "user accounts." Service accounts, API keys, and bot tokens fall outside the review scope or are bucketed under a "system accounts" category that receives rubber-stamp approval rather than substantive review.

"Having an inventory" is not the same as "managing credentials." Many CISOs say, "We have a credential inventory." But if the owner field in that inventory is empty, it's not an inventory, it's a list. A list tells you what exists. It doesn't tell you who is responsible. Governance doesn't function without the latter.

The cumulative effect of these gaps is a security posture that looks complete on paper but has a structural hole at its center. The organization has IAM. It has a CMDB. It has quarterly access reviews. It has compliance certifications. And it has 2,040 active credentials that no one owns, no one monitors, and no one can safely revoke. The tools are all present. The problem falls between them.

Real-World Breaches and Industry Data

Unattributed Keys are not a theoretical risk classification. They are a recurring pattern behind large-scale security incidents.

CSA's 2026 State of NHI Security report puts the governance reality into numbers. Among surveyed organizations, fewer than 30% had completed owner mapping for their NHI credentials. The remaining 70% were either unmapped, inaccurately mapped, or had never attempted mapping. That 70% represents Unattributed Keys. The 60% in our scenario is close to the industry average.

OWASP's NHI Top 10 ranks Improper Offboarding as the number-one NHI security risk. The Unattributed Key is the superset of the offboarding problem. The reason a departed employee's key goes unrevoked is that no ownership mapping existed in the first place. If you know the owner, you can revoke on departure. If you don't, you can't even determine whether the owner has departed.

The Verizon 2025 DBIR found that credential-based attacks accounted for approximately 20% of all analyzed breaches. This percentage has remained consistently high for years. Considering that a significant portion of breached credentials were ones "no one knew who they belonged to," Unattributed Keys serve as the silent foundation of credential-based attacks.

The CircleCI breach in January 2023 saw an engineer's device compromised by infostealer malware, leading to the theft of a session token that exposed customer secrets. Post-incident, CircleCI recommended that all customers rotate their secrets. But secrets with no identified owner have no one to receive the rotation recommendation. Unattributed credentials are a blind spot not just in prevention, but in incident response.

Uber's September 2022 breach demonstrated credential chaining at organizational scale. Credentials found in internal PowerShell scripts and network shares were used to pivot to AWS, Google Workspace, Slack, and HackerOne. Unattributed credentials scattered across internal systems were part of the attack chain. The larger the organization and the more acquisitions in its history, the more of these "nobody's credentials" accumulate.

GitGuardian's 2025 State of Secrets Sprawl report found that over 90% of secrets exposed in GitHub repositories were still valid five days after detection. Unattributed Keys have far longer validity windows. With no one to rotate them, they remain valid indefinitely, three years, five years, eight years. Without an expiration policy, the key lives forever.

Detection and Response Guide

Solving the Unattributed Key problem is not about revoking a single credential. It's about building an NHI governance framework. Short-term remediation and long-term systemic change must run in parallel.

Step 1: Full Inventory with Owner Mapping

Enumerate every NHI credential and map each one to an owner. Owner mapping must draw from multiple data sources: IAM creation logs (CloudTrail, Audit Logs), code repository commit history, CI/CD pipeline configuration files, Terraform/IaC change history, and Slack channel integration settings. A single source yields low mapping rates. Cross-referencing multiple sources is what pushes mapping above 60%. Credentials that cannot be mapped should be tagged "Unattributed" and triaged separately.

Step 2: Risk-Based Prioritization

Processing 2,040 Unattributed Keys simultaneously is infeasible. Prioritize by risk. The highest-priority targets are: credentials with write access to production environments, credentials unused for 90+ days (high probability of being unnecessary), credentials inherited from acquisitions that were never integrated, and service accounts with admin/root-level permissions. Addressing the top 10% by risk first is the realistic approach.

Step 3: Safe Decommissioning Process

Decommissioning a credential with no known owner requires a graduated approach. Don't delete immediately. First, reduce permissions, switch to read-only or block access to specific resources. Monitor for two weeks. If no failures occur, fully disable the credential. Monitor for another two weeks after disabling. If there are still no issues, delete. Each stage must be reversible. This process is tedious, but it's better than "we deleted the wrong key and production went down."

Step 4: Mandatory Ownership Tagging at Creation

Prevent new Unattributed Keys from being created by enforcing ownership tagging at the point of credential creation. In Infrastructure as Code, block deployments of service accounts that lack an owner tag. In API key provisioning portals, make the owner field mandatory. Automate regular audits for credentials missing owner tags. Systems are more effective than culture. Telling people to tag is training. Making it impossible to create without tagging is governance.

Step 5: Periodic Owner Validation

Even credentials with mapped owners can become Unattributed over time, when the owner departs, changes teams, or changes roles. Quarterly owner validation is required. Confirm the owner is still in the organization and still in a role relevant to the credential. If the owner has changed, reassign. If no owner can be identified, reclassify as Unattributed and begin the decommissioning process. For detailed implementation guidance on secret detection and management, see Git Secret Scanning: Complete Implementation Guide.

How Cremit Argus Solves the Unattributed Key Problem

The core challenge of the Unattributed Key is owner mapping. Manually tracing thousands of credentials to their creators is operationally infeasible. Cremit Argus automates this process.

Argus performs multi-source automated owner inference. It cross-analyzes IAM creation logs, code repository commit history, CI/CD pipeline configurations, and IaC change history to automatically infer each credential's creator and current maintainer. Where a single data source yields mapping rates of roughly 30%, Argus's multi-source cross-referencing pushes coverage above 80%.

Argus's NHI governance dashboard visualizes the entire credential landscape by ownership status. Total credential count, mapped count, Unattributed count, and risk-level classification, all in real time. A CISO can answer "How many Unattributed Keys do we have?" by opening a dashboard, not by commissioning a two-week audit.

Argus provides cross-platform visibility. AWS, GCP, Azure, GitHub, Slack, CI/CD systems, SaaS integrations, every platform where NHI credentials live, managed from a single pane of glass. When a single credential is used across multiple systems, Argus tracks every instance. Credentials inherited through acquisitions are brought into the same governance scope.

When an ownership change is detected, for example, when a mapped owner departs or changes teams, Argus automatically transitions the credential to a "reassignment required" state and notifies the relevant team. The goal is to reassign ownership proactively, before the credential becomes Unattributed.

Start NHI governance with Cremit Argus at cremit.io.

NHI Kill Chain Series Overview

This post is the eighth installment in the NHI Kill Chain series. Across nine posts, we analyze the most dangerous types of NHI credentials hiding inside organizations, each representing a distinct, and interconnected, risk.

A key exposed in a public repository, if left unrotated, becomes an Aged Key. A departed employee's key, if never ownership-mapped, becomes an Unattributed Key. Understanding how one credential management failure cascades into another risk category is the central purpose of this series.

1. Public Key: What Happens 4 Minutes After a .env Hits GitHub
2. Ghost Key: The Departed Developer Whose AWS Key Still Clocks In Every Morning
3. Aged Key: The Skeleton Key That Held Production Together for 3 Years
4. Zombie Key: Deleting It from Code Doesn't Mean It's Dead
5. Over-shared Key: What Happens When 10 People Share a Single Slack Bot Token
6. Shadow Key: Quietly Hardcoded Right Next to the Secrets Manager
7. Drifted Key: When the CI/CD Bot Auto-Attaches a DB Password to Jira
8. Unattributed Key: 3,400 Secrets and Nobody Knows Who Made Them (current post)
9. Series Summary: Full NHI Kill Chain Analysis and Unified Response Strategy (coming soon)

Previous post: NHI Kill Chain: Drifted Key, When the CI/CD Bot Auto-Attaches a DB Password to Jira

Next post: NHI Kill Chain: Series Summary, Full Analysis and Unified Response Strategy

Cremit is an NHI security company. [Learn more at cremit.io.](https://cremit.io)