Keychain accessibility controls determine when stored secrets can be read on a device and whether they survive backup or migration. The choice of accessibility class is a security decision, not a convenience setting, because it directly affects how long credentials remain exposed after compromise.
Expanded Definition
keychain accessibility describes the access conditions attached to a stored secret in an operating system credential vault, especially on Apple platforms, and it controls when that secret can be decrypted by an app or service. It is closely tied to device state, such as whether the device is unlocked, locked, or has ever been unlocked after reboot, and it may also determine whether the secret is included in backup or migration workflows. For NHI and mobile security teams, the key question is not whether a credential is stored, but under what conditions it becomes readable.
Definitions are generally consistent in principle, but usage in the industry is still evolving across app development, mobile device management, and secret handling guidance. The security impact becomes clearer when compared with broader secret governance in the OWASP Non-Human Identity Top 10, where persistent credentials and over-retention are common risk themes. Accessibility is not a substitute for encryption; it is a policy layer that shapes exposure windows and recovery behaviour. The most common misapplication is choosing a permissive accessibility class by default, which occurs when developers optimise for convenience and accidentally allow secrets to remain retrievable longer than the application’s threat model supports.
Examples and Use Cases
Implementing keychain accessibility rigorously often introduces availability constraints, requiring organisations to weigh reduced post-compromise exposure against the risk of blocked background access or failed restoration.
- A banking app stores a refresh token so it is only readable after the first device unlock, reducing exposure after a cold boot while still supporting normal user sessions.
- A healthcare app uses a stricter accessibility class for a session secret that should not survive device transfer, preventing recovery on a new handset after compromise.
- An enterprise MDM-managed app stores a device credential with migration restrictions so the secret does not silently appear in a backup restored onto an unmanaged device.
- An agentic workflow on mobile needs an API key for a local automation service, but the team intentionally avoids always-available storage because the agent’s tool access should pause when the device is locked.
- A security team reviews whether a secret should be present at rest at all, then aligns its storage choice with controls in NIST SP 800-53 Rev 5 Security and Privacy Controls for access enforcement and media protection.
These examples show that accessibility is a lifecycle decision, not a one-time implementation detail. It affects app launch behaviour, offline access, backup exposure, and the practicality of incident response when credentials must be revoked quickly.
Why It Matters for Security Teams
Security teams need to understand keychain accessibility because mis-set access classes can turn a well-encrypted secret store into a durable source of compromise. If a stolen device, forensic image, or malicious backup can still reveal active credentials, the operating system has not failed; the policy choice did. That is especially important for NHI scenarios, where service tokens, API keys, and refresh tokens may outlive the human user who provisioned them and can continue authorising systems long after trust should have ended.
From a governance perspective, keychain accessibility sits at the intersection of endpoint protection, secret lifecycle management, and privilege minimisation. A stronger setting can reduce persistence after loss or theft, but it may also break legitimate workflows if background services or recovery paths are not designed for it. Teams should treat this as part of credential risk assessment, not just app engineering. When combined with NHI practices, it helps ensure that machine credentials are not silently overexposed through device backups, shared profiles, or insecure migration paths. Organisations typically encounter the operational impact only after a lost device, failed restore, or incident response review, at which point keychain accessibility becomes 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 SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | Highlights risks from persistent machine credentials and weak secret lifecycle controls. | |
| NIST CSF 2.0 | PR.AA-01 | Identity and access governance supports controlling when secrets can be used or recovered. |
| NIST SP 800-53 Rev 5 | SC-28 | Protects information at rest, aligning with secret storage and exposure limitation choices. |
Review stored secrets for excessive persistence and remove any credential that should not survive compromise.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
