Manage identities and authentication information

What to do

1. 1

   Confirm identity and need before creation

   For one application, identify the authoritative identity source and approval role. Confirm the person or technical purpose and business need through the existing joining or engagement process. Only then create the approved account with the necessary rights. Personal identities remain uniquely assigned. Necessary shared accounts need dedicated justification and approval; technical identities need a purpose, ownership and appropriately independent ongoing oversight.

2. 2

   Configure and check the authentication procedure

   Derive factors and login protection from protection needs and attack scenarios. Include critical systems, technical access and fallback routes. Configure additional factors for critical information systems, protected transmission, suitable handling of failed attempts and session protection in the responsible system. Use suitable test cases for permitted and rejected login, necessary re-authentication and recovery. Keep settings, results and corrections in the existing configuration or change record.

3. 3

   Issue and recover authentication information securely

   Link the applicable authentication and recovery procedure from the concept. Before initial issue, replacement or reset, verify identity and authorisation through the trusted route. Issue securely only to the authorised recipient and keep receipt traceable without the secret value. Protect temporary initial credentials, vendor defaults, storage and transmission appropriately. Users receive the same applicable guidance. If information is lost or suspected to be compromised, invalidate it immediately and also check continuing sessions.

4. 4

   Complete changes and retirement effectively

   Adapt identity data and rights to the confirmed need. When authorisation ends, also check local or external access, sessions, tokens and other authentication information. A central account block is sufficient only for the access it actually covers. Transfer technical accounts still needed to a confirmed responsible role and change credentials known to departing people. The existing record connects approval, implementation, checked system state and open work. Reuse the existing access review.

5. 5

   Keep the chosen role model current

   If the target model is held in the Excel template, maintain one valid file in a shared location with appropriate access controls. Use version history or traceable file versions. Update profiles, permitted actions and approval roles when tasks or applications change materially. Reference specific entries and the valid version from the concept. Accounts and actual rights remain in the directory service or application; decisions stay in the existing access record. Optional tables add only information that is missing.

Worked example

An owner leaves but technical access is still needed

A person leaves the company. They had a personal administration account and maintained an integration account that is still needed. A local account is not covered by the central block.

Record the result

• Authoritative identity and rights source identifying the person or technical purpose and responsible role.
• Existing access record with confirmed need, approval, secure issue or recovery and actual completion.
• Valid role model and traceable significant changes without a second copy of actual account records.

Reuse the implementation across requirements

The references below show which requirements the measure contributes to.

Templates for your implementation

• 

  Template

  Access control concept with an Excel role matrix

  Adapt identity management, approvals and access reviews to your organisation. If you already maintain a suitable role model, link to it from the concept.

  Free ZIP · DOCX, ODT, PDF and XLSX · with editing instructions

  Request template