The server-side list of public keys allowed to authenticate to a user or system account. It is a trust registry, and if it is not reviewed and cleaned up, access can continue long after the original need has ended.
Expanded Definition
Authorized keys are the server-side trust registry for SSH or similar key-based access, listing which public keys may authenticate to a specific account. In NHI operations, they function as durable access grants, not just technical configuration, because each entry represents an identity assertion that can outlive the original need. Good governance distinguishes an authorized key from the private key held by the client, and from broader secret material such as API keys or certificates. That distinction matters because the server typically cannot tell whether the human or automation behind a key is still legitimate, only whether the key is still permitted.
Definitions vary across vendors on how much lifecycle metadata should be attached to authorized keys, but the security expectation is consistent: keys must be attributable, reviewed, and removable when no longer needed. This aligns with the control intent described in the NIST Cybersecurity Framework 2.0, where access governance and least privilege are operational requirements rather than paperwork. The most common misapplication is treating authorized keys as static setup artifacts, which occurs when teams add keys during onboarding but never verify ownership, expiry, or continued business need.
Examples and Use Cases
Implementing authorized keys rigorously often introduces administrative overhead, requiring organisations to balance frictionless automation against stronger access assurance.
- A build server uses an authorized key to push artifacts into production, and the key is tied to a named pipeline rather than a shared admin account.
- A contractor receives temporary SSH access through a tracked public key, then the entry is removed at offboarding instead of being left dormant.
- A platform team stores authorized key inventory alongside NHI lifecycle records so that access can be reviewed during periodic control checks, a practice reinforced in the Ultimate Guide to NHIs.
- A bastion host accepts only keys signed or approved through a central process, reducing ad hoc key sprawl across server fleets.
- A security team replaces long-lived shared keys with per-identity entries and short review intervals, following the access governance patterns described by NIST Cybersecurity Framework 2.0.
These examples all depend on the same principle: the authorized key is only safe when the entry can be traced to an owner, use case, and removal condition.
Why It Matters in NHI Security
Authorized keys are a frequent source of hidden persistence because they can bypass password resets, account lockouts, and some monitoring controls. When teams lose sight of which keys exist, who owns them, and where they are deployed, dormant access becomes normalised. That is especially dangerous in machine-to-machine environments where service accounts, deployment users, and shared operational accounts accumulate over time. NHI Mgmt Group research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotation, while 71% of NHIs are not rotated within recommended time frames, according to the Ultimate Guide to NHIs.
That same visibility gap applies to authorized keys: if a key is not inventoried, it cannot be reviewed, and if it is not reviewed, it cannot be retired with confidence. Mature governance therefore treats key cleanup as a recurring control, not a one-time hardening task. Organiszations typically encounter the operational impact only after a compromised account, a failed audit, or an unexpected remote login, at which point authorized keys become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Authorized keys are a form of non-human credential that must be inventoried and controlled. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management applies directly to server-side key-based authentication. |
| NIST Zero Trust (SP 800-207) | JA3 | Zero Trust expects continuous access validation, which static authorized keys can undermine if unmanaged. |
Track every authorized key, verify ownership, and remove stale entries on a fixed review cycle.
Related resources from NHI Mgmt Group
- What is the difference between workload identity and API keys for AI agents?
- How should security teams govern API keys used for generative AI access?
- What problem does ownership attribution solve for service accounts and API keys?
- How can organisations reduce the risk of stale API keys and machine tokens?
