The application must disable device identifiers after 35 days of inactivity unless a cryptographic certificate is used for authentication.

Description

<VulnDiscussion>Device identifiers are used to identify hardware devices that interact with the application much like a user account is used to identify an application user. Examples of hardware devices include but are not limited to mobile phones, application gateways, or other types of smart hardware. This requirement does not apply to individual application user accounts. This requirement is not applicable to shared information system accounts, application groups, or roles (e.g., guest and anonymous accounts) that are used by the application itself in order to function. Care must be taken to not disable identifiers that are used by the application in order to function. Inactive device identifiers pose a risk to systems and applications. Attackers that are able to exploit an inactive identifier can potentially obtain and maintain undetected access to the application. Applications need to track periods of device inactivity and disable the device identifier after 35 days of inactivity. This is usually accomplished by disabling the account used by the device to access the application. Applications that use cryptographic certificates for device authentication may use the expiration date assigned to the certificate to meet this requirement with the understanding that the certificate is created and managed in accordance with DOD PKI policy and can be revoked by a trusted certificate authority (CA). To avoid having to build complex device management capabilities directly into their application, developers should leverage the underlying OS or other account management infrastructure (AD, LDAP) that is already in place within the organization and meets organizational user account management requirements. Applications are encouraged to utilize a centralized data store such as Active Directory or LDAP to offload device management requirements and ensure compliance with policy requirements.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>