11.5.3 The relevant entities shall only permit identities assigned to multiple persons, such as shared …

Requirement

The relevant entities shall only permit identities assigned to multiple persons, such as shared identities, where they are necessary for business or operational reasons and are subject to an explicit approval process and documentation. The relevant entities shall take identities assigned to multiple persons into account in the cybersecurity risk management framework referred to in point 2.1.

Guidance

• Shared identities should be avoided unless strictly necessary for business or operational reasons (94). In such cases, their use must be formally justified, explicitly approved and properly documented. Examples of technical, procedural and governance controls to enhance their protection include (indicative, non-exhaustive list):
  • MFA enforcement;
  • Least privilege concept enforcement;
  • Time-bound or just-in-time access;
  • Checking out the shared credentials through a tool which logs who accessed the identity and when. If check-out is not possible, consider using privileged session recording or proxy-based access auditing;
  • Session attribution techniques to link shared identity use back to individual users;
  • Logging;
  • Credential vaulting with auto-rotation;
  • Prohibition of storing shared credentials in personal files, emails or messaging platforms;
  • Network segmentation so that shared account use is limited to isolated network segments or virtual environments; and
  • Mandatory training on acceptable use and accountability.
• These identities should be clearly recorded in the cybersecurity risk management framework, with appropriate controls in place to mitigate associated risks, including enhanced monitoring and accountability measures.

Examples of evidence

• Approval records for exceptions.

1. Översikt

1.1 Referenser

1.2 Identifierade krav

1.3 Relaterade regleringar

2. Identifierade krav

3. Relaterade regleringar

Länkade ärenden

• ENISA -