Your machines outnumber
your people 90 to 1
Service accounts. AI agents. CI/CD pipelines. API keys. Every one is an identity with permissions, yet most enterprises manage them with spreadsheets and hope. AuthHub treats Non-Human Identities as first-class citizens — with ownership, lifecycles, attestation, and automatic decommissioning.
The Retirement Debt Problem
When a human leaves an organisation, HR triggers a deprovisioning workflow. Access is revoked, accounts are disabled, equipment is returned. The process is imperfect but it exists.
When an AI agent's project finishes, when a service account's purpose ends, when a CI/CD pipeline is no longer needed — nothing happens. The credentials remain live. The permissions remain granted. The identity accumulates inside your perimeter like sediment.
This is retirement debt: a growing population of authenticated, privileged entities that nobody has owned since the quarter they were built.
What retirement debt looks like in practice:
- Scenario 1A data pipeline service account created 3 years ago for a project that finished 2 years ago. Still has read access to every patient record in the trust.
- Scenario 2An AI summariser agent whose controlling clinician left the NHS 6 months ago. Agent still runs nightly, accessing records under the departed clinician's delegated authority.
- Scenario 347 API keys issued to a vendor whose contract expired in March. Keys are still active because nobody knows which systems depend on them.
The AuthHub Approach
AuthHub manages Non-Human Identities with the same rigour as human identities — but adapted for the unique challenges of machine-to-machine relationships: no HR department triggers offboarding, no user clicks “I'm leaving,” and scale is orders of magnitude higher.
Every NHI Has a Named Human Owner
No anonymous service accounts. No shared keys without attribution. Every Non-Human Identity is bound to a human who is accountable for its existence, its permissions, and its continued business justification.
Default to Decommission
NHIs ship with a sunset date. Credentials carry short TTLs and expire unless actively renewed against a business justification. Survival by inertia is not available. If nobody attests that this identity is still needed, it dies.
Self-Repair on Human Departure
When an NHI's owner leaves (detected via SCIM), AuthHub doesn't just flag it. It cascades through the deputy chain, promotes a replacement, and if nobody accepts within 72 hours, escalates and eventually suspends the NHI. No orphans accumulate silently.
Security incidents bypass the cascade: immediate revocation of all NHI bindings for the departed user.
Tiered Governance
Not all NHIs are equal. A payment processing service in production is not the same as a dev-environment test bot. AuthHub applies governance proportional to risk — from CISO-level oversight for Tier 0 to lightweight auto-expiry for Tier 3.
| Tier | Scope | Missed Attestation | Approval |
|---|---|---|---|
| Tier 0 | Critical infrastructure | CISO approval required | Dual-gate + FIDO2 |
| Tier 1 | Production services | CISO approval required | Manager + tech owner |
| Tier 2 | Standard integrations | Auto-expire after grace | Tech owner only |
| Tier 3 | Dev/test/ephemeral | Auto-expire immediately | Self-service |
Connector Architecture
AuthHub doesn't replace your IAM platform. It extends it into the Non-Human Identity domain via bidirectional connectors. Your IdP remains the source of truth for human identities; AuthHub becomes the source of truth for everything else.
Your IdP pushes human lifecycle events to AuthHub. We detect departures, role changes, and team restructures — triggering NHI self-repair automatically.
REST + AuthZEN for CRUD, lifecycle transitions, attestation, certification campaigns. Your IGA workflows call AuthHub to register, attest, and decommission NHIs.
AuthHub pushes NHI state changes back to your SIEM, IGA, and PAM platforms. Revocations, containments, and attestation failures stream in real-time.
Supported Connectors
Microsoft Entra ID
GASCIM 2.0 provisioning, Conditional Access integration, Workload Identity Federation for Azure workloads
Okta / Auth0
GASCIM 2.0 lifecycle sync, event hooks for NHI governance signals, Actions integration for inline checks
Ping Identity
GASCIM provisioning, PingOne DaVinci orchestration flows, PingFederate token exchange (WIF)
CyberArk
BetaPrivileged credential vaulting for NHI secrets, just-in-time checkout, session recording for Tier 0 NHIs
HashiCorp Vault
GADynamic credential issuance, rotation orchestration, HSM-backed transit encryption for NHI key material
SailPoint
BetaIdentity governance workflows for NHI certification campaigns, compliance reporting, separation of duties enforcement
Saviynt
PlannedCloud-native identity governance, cross-cloud entitlement management, NHI discovery integration
AWS IAM / STS
GAWorkload Identity Federation via OIDC, role-based session tokens, cross-account NHI management
Google Cloud IAM
GAWorkload Identity Federation, service account key rotation, Cloud HSM integration for signing
Questions for Your Architecture Review
These are the questions we ask enterprises during discovery. If you can't answer them with confidence, your NHI estate is a risk you haven't quantified.
How many Non-Human Identities exist in your estate right now? Who owns each one?
If a service account's owner left today, how long before someone notices the NHI is unmanaged?
Can you revoke a specific AI agent's write access without killing the entire service?
When did you last verify that every production NHI still has a valid business justification?
If your model provider becomes non-compliant tomorrow, which agents are affected and how fast can you respond?
How many API keys in your estate were issued to vendors whose contracts have since expired?
Can a CISO demonstrate — right now, in this room — that a specific agent can be contained in under 5 seconds?
Where NHI Management Fits
AuthHub's NHI management layer sits alongside — not on top of — your existing IAM stack. It extends your identity governance into the non-human domain without disrupting current workflows.
Ephemeral Workloads: NHIs Without the Overhead
Not every machine identity needs a persistent record. Kubernetes pods, CI runners, serverless functions, and short-lived batch jobs exist for seconds or minutes. Creating a full NHI registry entry for each would flood the system. AuthHub handles these via Workload Identity Federation (WIF) — zero persistent credentials, zero registration, zero cleanup.
Persistent NHIs
Long-lived identities that outlast individual requests. Service accounts, AI agents, medical devices. Require ownership, attestation, lifecycle management.
- Full registry entry with named owner
- State machine (13 states)
- Certification campaigns + renewal
- Credential rotation + vaulting
- Self-repair on owner departure
Ephemeral Workloads
Short-lived compute that authenticates via token exchange. No persistent credentials, no registry entry, no cleanup needed. Identity proven cryptographically at runtime.
- Workload Identity Federation (RFC 8693)
- SPIFFE/SPIRE SVID attestation
- Tokens valid 60s–15min (configurable)
- No stored credentials to rotate or leak
- Scope-limited by issuer policy + DPoP binding
How Ephemeral Authentication Works
POST /oauth/token (grant_type: token-exchange) with DPoP proof| Platform | Identity Source | Token Type |
|---|---|---|
| GKE / Google Cloud | Workload Identity (OIDC) | Google-signed ID token |
| EKS / AWS | IRSA / Pod Identity | AWS STS token |
| AKS / Azure | Workload Identity (Entra) | Entra ID token |
| GitHub Actions | OIDC token (actions/jwt) | GitHub-signed JWT |
| GitLab CI | CI_JOB_JWT_V2 | GitLab-signed JWT |
| SPIFFE/SPIRE | X.509 SVID attestation | SPIFFE JWT-SVID |
When to use persistent vs ephemeral: If the identity outlives a single compute instance and needs ownership, attestation, and decommissioning — create a persistent NHI. If it's a pod, a CI job, or a function that starts, runs, and dies — use WIF. AuthHub supports both patterns from the same platform.
Start managing your Non-Human Identities
See how AuthHub extends your existing IAM investment into the machine identity domain.