# Non-human identities

Expose ownerless keys, excessive privileges and rotation dependencies.

SecNet.Work | 2026.10 | 2026-10-21

Service accounts, workload identities and API keys do not behave like human accounts. MFA alone does not explain automation security; ownership, issuance context, least privilege and revocation matter. Where supported, managed or short-lived identities can reduce long-lived secrets. Verify product support and workload compatibility.

## Work boundary
Do not upload production secrets. Record masked identifiers, ownership and permission scope instead of secret values.

## Process

### 1. Assign identity ownership
Link workload, business/technical owners, environment and last use. Verify whether an apparently unused identity supports a periodic critical job. Do not blindly delete ownerless identities.

Expected evidence: Identity–workload–owner record

### 2. Constrain privilege and trust
Define resource, action and environment boundaries. For federation, check which workload may obtain a token. Detect shared development/production keys without copying secret values into records.

Expected evidence: Effective privilege and trust relationship

### 3. Rehearse rotation
Map consumers and outage impact. Test new-identity activation, old-identity revocation and rollback in a controlled environment. Moving a key to a vault does not revoke old copies.

Expected evidence: Rotation and old-key rejection test

### 4. Monitor the lifecycle
Monitor workload retirement, owner departures and privilege increases. Assign expiry, renewal and revocation responsibilities. Distinguish the last successful test from actual production coverage and remaining dependencies.

Expected evidence: Lifecycle and exception record

## One control, three perspectives

### Operator
What consumes this identity?
Validate dependencies before rotation.
Evidence: Consumers and rotation test

### Auditor
Does the old secret still work?
Verify revocation with an authorized negative test.
Evidence: Masked ID and rejection result

### Leader
What is the risk of ownerless automation?
Assign a business owner and fallback.
Evidence: Ownership and continuity record

## Evaluate evidence

**Claim:** The old key is disabled.

**Weak support:** A new key was added to the vault.

**Stronger support:** The old key’s revocation, masked identifier and rejected-access test are recorded.

**Rationale:** Adding a new secret does not disable the old one. Assess old consumers and caches separately.

## Decision desk
Two environments share a service key with no known owner.
Start: start

### start
First decision?

- **Map consumers and separate environment privileges** (good)
  You plan least privilege with business impact visible. Also test retirement of the old identity.
  Next: verify

- **Delete the key immediately** (risk)
  Unknown dependencies may stop critical work. Use a controlled change and revocation plan.
  Next: repair

- **Close without a rationale** (incomplete)
  Deferring an open issue is not closure evidence. Record the uncertainty, owner and next verification step.
  Next: revise

### verify
The new identity works, but the old key is still accepted.

- **Revoke the old identity as planned and test rejection** (good)
  Completion includes closing the old path. Verify consumer and cache coverage.
  Next: planned

- **Accept the claim without testing** (risk)
  The initial claim and observed result differ. Support closure with a repeatable check in the same scope, rather than a promise or ticket status.
  Next: revise

### repair
Deleting the identity stopped a period-end job.

- **Own the incident, perform approved recovery and record dependencies** (good)
  Recovery is itself a controlled authorization action. Track temporary access and permanent ownership.
  Next: planned

- **Delete the earlier record and close** (risk)
  Deleting the earlier decision undermines learning and accountability. Link the new action to the prior record and keep the rationale and residual risk visible.
  Next: revise

### supported
This decision is supported by the evidence in the example. Verify closure conditions in your own scope.

### revise
The decision lacks support. Record the rationale and required evidence, then reassess.

### planned
A remediation path is defined. Keep the matter open until implementation and verification are complete.

## Worked example
Entirely fictional.
- Masked ID: svc-***-21
- Workload: Example transfer job
- Owner: Data platform owner
- Permission: Write to destination only
- Consumer: Synthetic batch job
- Revocation test: Old identity rejected

## Closure checklist
- [ ] No secret values recorded.
- [ ] Business and technical owners exist.
- [ ] Environment and resource privileges constrained.
- [ ] Old-identity revocation verified.

## Official sources
- [Microsoft — Securing service principals](https://learn.microsoft.com/en-us/entra/architecture/service-accounts-principal)
- [Microsoft — Protect identities and secrets](https://learn.microsoft.com/en-us/entra/fundamentals/zero-trust-protect-identities)

https://secnet.work/learn/toolkits/non-human-identities