Copying a public key into an authorized-keys file creates an access grant that can outlive the person, project, or automation that justified it. SSH keys need the same ownership, approval, review, and termination discipline as other privileged identities.
\nNIST Interagency Report 7966 addresses enterprise management of interactive and automated access using Secure Shell. It focuses on SSH user-key provisioning, termination, and monitoring, including the risks created when keys grant high privileges or support unattended automation. The publication treats key management as an enterprise access-control problem rather than solely a cryptographic file-format issue.
\nSSH public-key authentication can remove password use from a connection while leaving authorization decisions in distributed server files and device configurations. Automated keys may connect systems with broad privileges and no person present at each use. Effective control therefore depends on knowing which key is accepted where, who or what owns it, what restrictions apply, and how the grant is removed.
\nThe 2015 NIST report should be applied with current product and cryptographic guidance. It does not make every SSH key inappropriate, prescribe one management product, or establish that a discovered key is malicious. Host keys, user keys, certificates, agent forwarding, and secrets embedded in scripts present different risks. Removing an unidentified automation key without dependency analysis can cause an outage.
\nDiscover authorized keys using supported host, device, configuration-management, and identity tooling. Normalize fingerprints rather than copying private material. Build a grant record for each key-to-account-to-target relationship, including owner, business process, privilege, source, creation evidence, last observed use, review date, and revocation method. Investigate orphaned keys before removal and isolate high-risk unknowns through change control.
\nMove routine access toward centrally governed provisioning or short-lived SSH certificates where product support and risk justify it. For retained static keys, use unique keys per trust purpose, protect private keys, restrict authorized-key options where supported, and monitor use. Tie employee and vendor termination to a tested SSH revocation step. Give automation owners a rotation and recovery procedure that avoids sharing one key across unrelated systems.
\nKeep fingerprint inventories, target-account mappings, approvals, owner attestations, use telemetry, exception records, and revocation test results. Sample a terminated or test identity and prove that access is denied on every recorded target while required jobs continue with replacement credentials. Reconcile the inventory with configuration changes and newly observed fingerprints on a defined schedule.
\n