Ownership Attribution at Scale: Mapping NHIs to Humans

Every NHI security programme eventually hits the same wall: "we found the risky credential, but nobody knows whose it is." Rotation stalls. Investigations open Jira tickets on entire teams. The programme grinds to a halt while people argue about who has to fix what.

Ownership attribution — the systematic mapping of every NHI to a responsible human — is the invisible spine of NHI security. Get it right and remediation is a five-minute Slack DM. Get it wrong and every finding is a mystery.

The failure mode we see most often is treating ownership as a one-time data-entry exercise. Teams build the inventory, assign owners manually, and then — because maintaining ownership is tedious — the attribution data rots. Six months later, 30% of owners have changed teams, 10% have left the company, and a handful of NHIs have owners who genuinely do not know they are responsible for a production credential. The attribution is worse than no attribution, because it provides false confidence.

Signals that produce owners

The relative reliability of these signals matters for weighting the fusion model. Commit history is highly reliable when the repository has good hygiene (no bulk-commit bots, CODEOWNERS enforced) and highly unreliable when it does not. Deployment metadata is reliable for infrastructure-as-code shops and unreliable for teams with manual deployment workflows. Cloud resource tags are reliable in organisations where tagging is a hard requirement at provisioning time and completely unreliable where they are optional.

The implication is that the attribution model needs to be tenant-configurable — the weights that work for a platform engineering team with rigorous IaC practices are different from the weights that work for a product team with a mix of manual and automated deployment processes.

The attribution algorithm in practice

# Ownership attribution — multi-signal fusion
attribution:
  identity: svc-payments-processor.production

  signals:
    git_blame:
      result: [email protected]
      confidence: 0.82
      basis: "Last committer to payments-processor/iac/service-account.tf"

    helm_chart_owner:
      result: [email protected]
      confidence: 0.91
      basis: "CODEOWNERS: /charts/payments-processor @alice @payments-team"

    namespace_team:
      result: payments-team
      confidence: 0.65
      basis: "Namespace payments-prod mapped to payments-team via org manifest"

    hris_validation:
      alice_status: active
      payments_team_lead: [email protected]

  fusion:
    primary_owner: [email protected]
    composite_confidence: 0.87    # above 0.80 threshold → auto-assign
    team: payments-team
    team_lead: [email protected]    # escalation target if alice unavailable
    method: weighted_sum
    review_required: false

  audit:
    attributed_at: 2026-09-08T09:14:22Z
    signals_used: [git_blame, helm_chart_owner, namespace_team, hris_validation]
    attribution_version: v2.4.1

The composite confidence score is the operationally important output. Above 0.80, the attribution is auto-assigned and Alice receives a Slack notification that she is the registered owner of this service account, with a link to the inventory record and an option to dispute. Below 0.80, the record enters the confirmation queue and Bob (as team lead) is asked to confirm or reassign within 48 hours.

The dispute mechanism is as important as the auto-assignment. Alice should be able to say "this is not mine — talk to Charlie" with one click. If disputes require a Jira ticket or an IT helpdesk request, people simply will not dispute incorrect attributions, and the ownership data will become quietly wrong.

Fusion, not single-source

None of these signals alone is high-precision. Commit history breaks when a human committer changes teams. Tags rot. On-call rotates. The trick is fusion: a weighted score across all signals, with a confidence threshold below which the identity is flagged as "needs human confirmation."

The fusion model has a useful side effect: it is self-documenting. Every attribution record carries a full provenance trail — which signals contributed, what each signal said, and what weight it was assigned. When an auditor asks "how do you know Alice owns this service account," the answer is not "we checked" — it is "git blame said Alice at 82% confidence, the Helm CODEOWNERS file said Alice at 91% confidence, and HRIS confirms she is active. Combined confidence: 87%."

Edge cases that break naïve attribution

The 80/15/5 distribution above applies to organisations with reasonable engineering hygiene. In reality, several edge cases create hard attribution problems that require explicit handling.

Handling departures

• Detect fast. HRIS webhook → orphan detection worker runs same day, not next quarter.
• Reassign, do not just alert. The identity is offered to the team lead of the departed owner's team. The lead has 72 hours to accept or delegate. After that, the identity is quarantined.
• Preserve audit. The old owner remains on the audit trail. Attribution history is append-only.
• Retire, do not just rotate. Many orphaned identities are also idle. If HRIS says the human left and the identity has not been used in 30 days, retire it entirely.

The quarantine-after-72-hours rule is the policy that consistently makes the biggest difference in departure-related risk. Without a deadline, the reassignment request sits in Bob's inbox indefinitely while the identity remains active with an acknowledged absent owner. The deadline creates urgency without being punitive — 72 hours is enough time for a team lead to reassign thoughtfully, but short enough that the identity does not remain in limbo for weeks.

The retire-if-idle rule is equally important. Many service accounts associated with departing employees are also idle — the employee left, their service stopped being maintained, and the account has been making no calls for 30 or 60 days. Combining the departure signal with the idle signal allows the system to recommend retirement rather than reassignment, which is almost always the right outcome for an unmaintained service.

Keeping attribution fresh

Attribution freshness requires three continuous processes running in parallel.

• HRIS streaming. Every employee departure, team transfer, and role change triggers an attribution review for all NHIs attributed to the affected human. This runs within hours of the HRIS event, not on the next weekly batch.
• Deployment event ingestion. Every time a service account is referenced in a new deployment — a new Helm chart, a Terraform apply, a CI/CD run — the attribution signals are refreshed. If the Helm chart has a new CODEOWNERS entry, that changes the attribution.
• Periodic dispute resolution review. Every 30 days, owners receive a "do you still own these identities?" digest. One-click confirm or reassign. This catches the silent drift that does not trigger any automated signal — the engineer who moved to a different team but whose old service accounts were never transferred.

The periodic digest is the mechanism that most organisations skip because it feels like noise. In practice, it resolves 5–10% of attribution records every month — not through automated signals, but through the simple act of asking owners whether their ownership is still accurate. That 5–10% monthly churn rate means that without the digest, the attribution data would be 40–50% stale within a year.

A pragmatic implementation

If you are building this: start with commit history + HRIS as the minimum viable ownership graph. Ship the "needs confirmation" queue on week one. Add deployment metadata signals on week two. Do not wait for perfection — an imperfect ownership graph is transformative on day one, and a perfect one takes six months.

If you are buying: verify that ownership is a first-class capability, not a spreadsheet import. Ask specifically how the platform handles departures, disputes, and delegation. The answer will tell you whether the vendor has actually operated an NHI programme or only observed one.

The most revealing question to ask any vendor: "Show me the UI where an engineer disputes an incorrect attribution." If the answer requires a support ticket, if it takes more than three clicks, or if the vendor looks uncertain — attribution is a secondary feature, not an engineered capability. The difference matters because attribution is not a one-time data import; it is an ongoing operational function that your identity team will interact with every day.

TigerIdentity's ownership attribution worker is built as a first-class service in the platform architecture, not bolted onto discovery as an afterthought. It runs continuously, accepts webhook events from HRIS, git, and deployment systems, maintains a confidence-scored attribution record for every NHI in the graph, and exposes a dispute/delegation API that takes under three seconds from receipt to updated graph node. The operational consequence is that your identity team spends less time on attribution archaeology and more time on the remediations that attribution enables.