Access Management Standard (SFA 06-107.2.1)

SFA must control access to its systems, networks, applications, and data, and keep that access current.

• Set up logical access controls for all in-scope systems and assets, including at minimum both discretionary controls (owners can grant or restrict access) and role-based controls (access tied to job role) (06-107.2.1.1.1).
• Review who has access at least every 12 months (or sooner using a risk-based approach), and revoke or update access when it is no longer needed; define triggers, such as separation or a change in data classification, that require immediate revocation, done automatically where possible (06-107.2.1.1.2).
• Restrict access to repositories holding confidential data to only authorized users, and add extra controls where needed, such as multi-factor authentication, biometrics, or other checks (06-107.2.1.1.3).
• Let authorized users grant or restrict access within the rules of the access control policy, and for high-risk systems additionally enforce mandatory (non-discretionary) controls based on defined security attributes (06-107.2.1.1.4).

Accounts must be created, managed, monitored, and closed through defined processes, with special care for privileged and shared accounts.

• Document account management processes covering which account types are allowed, group and role membership, access levels, an approval process for new accounts, unique IDs for each account, and monitoring of account usage (06-107.2.1.2.1).
• Disable accounts promptly when they expire, no longer belong to a user, violate policy, or go inactive; move accounts that cannot be disabled to a more restrictive class after separation; and have a process for mass-disabling centrally managed accounts (06-107.2.1.2.2).
• Define session-lock requirements using a risk-based approach (based on data sensitivity, impact of unauthorized access, business needs, and regulations), keeping the lock in place until the user re-authenticates (06-107.2.1.2.3).
• Manage privileged accounts carefully: define which account types may receive privileged access, keep privileged accounts off individual email addresses, require review and approval and a valid business case, require multi-factor authentication, and revoke the access when the work is done (06-107.2.1.2.4).
• Control shared or group accounts: limit them to essential uses, set authentication requirements, monitor their activity, keep an audit trail that ties actions back to individuals, and never use them where duties must be separated (06-107.2.1.2.5).
• Monitor user, service, shared/group, and privileged account activity regularly to spot unusual behavior, and report anything anomalous to the right people as soon as possible (06-107.2.1.2.6).
• Use automated tools to create, enable, change, review, disable, and remove accounts, and automatically remove or disable temporary and emergency accounts after a defined time or condition (06-107.2.1.2.7).

Passwords and other "authenticators" (the things that prove who you are) must be issued, protected, and reset securely.

• Manage authenticators from start to finish: verify identity before issuing them, set strong initial content, change default passwords before first use, refresh them on a schedule or after key events, protect them from disclosure, and have a documented process for mass password resets (06-107.2.1.3.1).
• Set password rules by account type using a risk-based approach, including creation and usage rules, prompt changes for temporary or compromised passwords, and encryption or hashing in transit and storage; passwords must meet one of two complexity options (10+ characters changed yearly, or 12+ characters that do not expire), both checked against breached-password lists (06-107.2.1.3.2).
• Limit the feedback shown during login so it does not reveal which part of a credential was wrong (for example, do not tell the user whether the username or the password was incorrect) (06-107.2.1.3.3).
• Set authentication requirements for accessing cryptographic modules that match how sensitive those modules are, and allow only authorized roles or users to reach them (NIST 800-53 IA-07).
• Document and maintain a list of approved external authenticators, and deny all others by default (06-107.2.1.3.4).

Shared collaboration devices and idle screens must not become an open door to SFA systems or data.

• Prevent outside users from remotely turning on collaborative devices such as smart displays and interactive whiteboards, and show people at the device when it is in use (dedicated video conferencing systems that someone must call to connect are excluded) (06-107.2.1.4.1).
• Lock a device after a defined period of inactivity and keep it locked until the user re-authenticates (06-107.2.1.4.2).
• Hide whatever was on screen behind the device lock (for example, a blank screen or approved pattern) so no SFA data stays visible while the session is locked (06-107.2.1.4.3).

No one should have more access than their job requires, and sensitive duties should be split among different people.

• Separate duties as much as possible and review them at least every 12 months, for example splitting support functions among different people and keeping those who manage access controls from also managing audit functions (06-107.2.1.5.1).
• Apply least privilege to every account, allowing only the access needed to do assigned tasks (06-107.2.1.5.2).
• Configure systems so non-privileged users or accounts cannot run privileged functions (06-107.2.1.5.3).

Every user, process, and device must be uniquely identified and verified before being allowed into SFA systems, with multi-factor authentication for sensitive access.

• Use a unique identification scheme (such as employee ID numbers) to uniquely identify and authenticate every user across SFA systems and assets (06-107.2.1.6.1).
• Require multi-factor authentication so that one factor comes from a device separate from the system being accessed, and any such device is approved and secured (06-107.2.1.6.2).
• Require multi-factor authentication for systems that store, process, or transmit confidential data, such as cloud applications and email (06-107.2.1.6.3).
• Identify and verify users, the processes acting for them, and devices before granting access to any system (06-107.2.1.6.4).
• Manage identifiers (user IDs, process IDs) by authorizing them, making them unique and unchangeable, preventing reuse, and not using email addresses as identifiers; manage them centrally where feasible (06-107.2.1.6.5).
• Define processes to uniquely identify and authenticate non-SFA users (vendors) and any processes acting on their behalf (06-107.2.1.6.6).
• Enforce access controls for remote access, including two-factor authentication, VPN and/or Secure Access Service Edge (SASE) architecture, encrypted connections, and other usage restrictions (06-107.2.1.6.7).
• Define when users must re-authenticate, such as after inactivity, when reaching sensitive resources, after changing location, device, or network, or after system updates (06-107.2.1.6.8).
• Enforce access controls for wireless access (authorize connections first, monitor and filter traffic, require authentication and encryption), and logically isolate vendor and visitor networks from internal networks (06-107.2.1.6.9).
• Tag each individual identifier with a status characteristic (such as contractor, student, or guest) and protect the attributes tied to each identifier from unauthorized access or change (06-107.2.1.6.10).
• Require the appointing supervisor or authorizing official to approve identity proofing and credential issuance before access is granted (06-107.2.1.6.11).
• For non-organizational users, follow defined identity management profiles and trust frameworks (such as InCommon) when accepting external identities and credentials (06-107.2.1.6.12).

Logon attempts must be limited, users must see the required use notices, and sessions must close cleanly.

• Limit consecutive failed logon attempts within a defined time period, and automatically lock the account once the limit is reached so an administrator must unlock it (06-107.2.1.7.1).
• Show a use-notification banner, created or reviewed by the Privacy Officer, before granting access; keep it on screen until the user acknowledges the terms and logs on, and require acknowledgment on publicly accessible systems too (NIST 800-53 AC-08).
• Document any actions users are allowed to perform without identification or authentication, such as updating default system settings (06-107.2.1.7.2).
• Invalidate session identifiers when a user logs out or a session otherwise ends, to protect the authenticity of the session (06-107.2.1.7.3).