Access Control 3.1.15 (3.1.15)

Does your organization allow employees or administrators to remotely access systems with administrative or privileged capabilities?

Do you have remote access tools that allow execution of commands with elevated privileges (such as remote PowerShell, SSH with sudo, or remote desktop with admin rights)?

What is the difference between authentication and authorization in the context of this control?

Authentication verifies who you are (username/password, MFA), while authorization determines what you are allowed to do. This control requires authorization beyond authentication - even after a user successfully authenticates remotely, they must receive explicit authorization before executing privileged commands. Multi-factor authentication alone does not satisfy this control.

Does this control require approval for every single privileged command executed remotely?

Not necessarily for every individual command, but authorization must be verified before privileged access is granted. This can be implemented as session-level authorization (approval required before starting a privileged remote session), time-based authorization (access granted for approved maintenance window), or ticket-based authorization (access tied to approved change request). The key is that authorization is explicit and verified, not automatic based on role alone.

How do we define what constitutes a 'privileged command' or 'security-relevant information' in our environment?

Privileged commands are those that control, monitor, or administer system security functions - such as creating users, changing security configurations, accessing audit logs, or modifying access controls. Security-relevant information includes anything that could impact security functions or enable bypassing security controls - such as security configurations, encryption keys, audit logs, or system architecture details. Organizations should document their definitions based on their specific systems and risk assessment.

Can we use role-based access control (RBAC) to satisfy this control's authorization requirement?

RBAC alone is typically insufficient because it authorizes based on role assignment, which is usually a standing authorization. This control requires verification of authorization before each privileged remote access session or operation. RBAC can be part of the solution if combined with session-specific authorization mechanisms such as approval workflows, just-in-time access provisioning, or time-limited privilege elevation.

What should we do about emergency or break-glass remote privileged access that cannot wait for approval?

Emergency access should still have authorization controls, but they can be different from normal access. Acceptable approaches include: pre-authorized emergency access with enhanced monitoring and immediate post-access review, automated authorization based on specific emergency conditions with real-time alerting, or time-limited emergency credentials that are automatically revoked and reviewed. The key is that emergency access is logged, monitored, and reviewed to ensure it was legitimately used.

Does this control apply to service accounts or automated processes that execute privileged commands remotely?

Yes, this control applies to any remote execution of privileged commands, including automated processes. Service accounts and automation should have documented authorization for their privileged remote access, typically through approved configuration management, defined in security architecture, and subject to regular review. The authorization may be standing but must be explicit, documented, and periodically validated rather than implicit or uncontrolled.