How Identity and Access Management Supports IRS Publication 1075

Account Management

a. Define and document the types of accounts allowed and specifically prohibited for use within the system;

b. Assign account managers;

c. Require conditions for group and role membership;

d. Specify:

1. Authorized users of the system;

2. Group and role membership; and

3. Access authorizations (i.e., privileges) and other attributes (as required) for each account.

e. Require approvals by the system owner or designated representative for requests to create accounts;

f. Create, enable, modify, disable and remove accounts in accordance with agency account management procedures prerequisites;

g. Monitor the use of accounts;

h. Notify account managers and designated agency official within:

1. 24 hours when accounts are no longer required;

2. 24 hours when users are terminated or transferred; and

3. 24 hours when system usage or need-to-know changes for an individual;

i. Authorize access to the system based on:

1. A valid access authorization;

2. Intended system usage; and

3. Under the authority to re-disclosed FTI under the provisions of IRC § 6103;

j. Review accounts for compliance with account management requirements annually for user account and semi-annually for privileged accounts;

k. Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group; and

l. Align account management processes with personnel termination and transfer processes.

In practice: Each account type is documented and has a named owner. Requests for group or role membership go through the access request workflow, and reviewers regularly confirm who still needs each account.

Account Management | Automated System Account Management

Support the management of system accounts using automated mechanisms.

In practice: New, changed and departing staff trigger account changes automatically in the identity governance platform, and the account owner and the security team get a notification each time.

Account Management | Removal of Temporary and Emergency Accounts

Automatically disable and remove temporary and emergency accounts after two (2) business days.

In practice: A temporary or emergency account is created with an end date of two business days, and the platform disables and removes it when the date arrives, so nobody has to remember to clean it up.

Account Management | Disable Accounts

Disable accounts within 120 days when the accounts:

a. Have expired;

b. Are no longer associated to a user or individual;

c. Are in violation of organizational policy; or

d. Have been inactive for 120 days for non-privileged accounts and 60 days for privileged accounts

In practice: A report, often run weekly, lists expired, orphaned and inactive accounts. The help desk disables them within the stated window, and privileged accounts are flagged sooner because their inactivity limit is shorter.

Account Management | Automated Audit Actions

Automatically audit account creation, modification, enabling, disabling and removal actions.

In practice: Every account creation, change, disable and removal writes a log entry automatically, so an analyst can see who or what touched an account, and when, without asking an administrator.

Account Management | Privileged User Accounts

a. Establish and administer privileged user accounts in accordance with a role-based access scheme; an attribute-based access scheme

b. Monitor privileged role or attribute assignments;

c. Monitor changes to roles or attributes; and

d. Revoke access when privileged role or attribute assignments are no longer appropriate.

In practice: Administrators receive privileged accounts through a role-based request, and the security team gets an alert whenever someone is added to or removed from a privileged role. Access is pulled back when the job changes.

Account Management | Restrictions on Use of Shared and Group Accounts

Only permit the use of shared and group accounts that meet agency-defined conditions for establishing shared and group accounts.

In practice: Shared and group accounts are listed in an inventory with a named owner and a written reason. Anything outside the agency's stated conditions is replaced with individual accounts.

Account Management | Account Monitoring for Atypical Usage

a. Monitor system accounts for agency-defined atypical usage; and

b. Report atypical usage of system accounts to agency-defined personnel or roles.

In practice: Sign-in reports flag unusual activity, such as a login at an odd hour or from an unexpected place, and route it to the security team's queue for follow-up.

Account Management | Disable Accounts for High-Risk Individual

Disable accounts of users posing a significant risk within one (1) day of discovery of the risk.

In practice: When the security team flags a person as a significant risk, a short runbook lets the help desk disable that person's accounts through the identity platform within one day.

Access Enforcement

Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.

(IRS-Defined): Users having accounts with administrator access privileges may access those accounts only from agency-owned or authorized contractor systems.

In practice: Access to systems holding federal tax information follows the roles people were given, and administrator accounts work only from agency-owned or authorized contractor devices, checked at each sign-in.

Separation of Duties

a. Identify and document separate duties of individuals to prevent harmful activity without collusion; and

b. Define system access authorizations to support separation of duties.

In practice: Request rules keep one person from holding two conflicting duties, such as creating a record and approving it. A report shows any conflicts that slip through so a manager can fix them.

Least Privilege

Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.

In practice: Staff receive roles built around their actual tasks, and managers periodically confirm the access is still needed. Administrator rights are granted just in time rather than left on permanently, and shared administrator credentials are kept in a privileged access vault.

Least Privilege | Authorize Access to Security Functions

Authorize Access for Security Functions to:

a. Explicitly authorize access to security functions deployed in hardware, software, and firmware; and

b. Security-relevant information.

In practice: Administrator access to security tools is a defined role that needs a recorded request and sign-off. People who finish that work have the elevation removed.

Least Privilege | Non-Privileged Access for Nonsecurity Functions

Require that users of system accounts or roles with access to security functions including but not limited to: establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited and setting intrusion detection parameters use non-privileged accounts or roles, when accessing nonsecurity functions.

(IRS-Defined): Prohibit accounts with administrative privileges (including local administrator rights) from web browsing and other Internet connections outside of the local protected boundary unless such risk is accepted in writing by the agency's CISO.

(IRS-Defined): Block accounts with administrative privileges (including local administrator rights) from access to email unless such risk is accepted in writing by the agency's CISO.

In practice: Administrators use one account for admin tasks and a separate everyday account for email and browsing, so a phishing click in the everyday account does not carry admin rights.

Least Privilege | Privileged Access by Non-Organizational Users

Prohibit privileged access to the system by non-organizational users.

In practice: Members of the public who sign in to agency portals are held in a separate account population, policy blocks administrator role assignment to that population, and a review looks for any that were granted by mistake.

Least Privilege | Review of User Privileges

a. Review annually the privileges assigned to FTI to validate the need for such privileges; and

b. Reassign or remove privileges, if necessary, to correctly reflect organizational mission and business needs.

In practice: Each year, system owners receive a list of who holds privileges on systems with federal tax information and mark each one keep or remove. Removals are carried out and the decisions are saved.

Least Privilege | Auditing Use of Privileged Functions

Audit the execution of privileged functions.

In practice: Administrator sessions are recorded, and the log shows which privileged commands were run, by which named person, and when. The security team can pull that history on request.

Unsuccessful Logon Attempts

a. Enforce a limit of three (3) consecutive invalid logon attempts by a user during a 120-minute period; and

b. Automatically lock the account for 15 minutes or until released by an administrator when the maximum number of unsuccessful attempts is exceeded.

In practice: The directory locks an account after three failed sign-ins in a 120-minute window. It stays locked for 15 minutes, or until an administrator unlocks it after confirming who is calling.

Remote Access

a. Establish and document usage restrictions, configuration/connection requirements and implementation guidance for each type of remote access allowed; and

b. Authorize each type of remote access to the system prior to allowing such connections.

Supplemental Guidance: [text omitted] Any remote access where (i) FTI is accessed or (ii) an FTI environment is administered over the remote connection must be performed using multifactor authentication. [text omitted]

In practice: Each kind of remote access, such as VPN or remote desktop, is written down and authorized before use. The sign-in service requires MFA, so remote staff face a second check.

Identification and Authentication (Organizational Users)

Uniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users.

In practice: Every employee signs in with their own named account through one single sign-on service, so activity in each application can be traced to a single person.

Identification and Authentication (Organizational Users) | Multifactor Authentication to Privileged Accounts

Implement multi-factor authentication for access to privileged accounts.

Supplemental Guidance: Regardless of the type of access (i.e., local, network or remote) privileged accounts must always authenticate using multifactor options, except in the event of direct terminal access from within a restricted area (as defined in Section 2.B.3, Restricted Area Access). [text omitted]

In practice: Administrators must complete a second step, such as a code or security key, every time they sign in to a privileged account, in addition to their password.

Identification and Authentication (Organizational Users) | Multifactor Authentication to Non-Privileged Accounts

Implement multi-factor authentication for access to non-privileged accounts.

Supplemental Guidance: Regardless of the type of access (i.e., local, network or remote) non-privileged accounts must always authenticate using multifactor options. [text omitted]

In practice: Regular staff also add a second sign-in step, such as a phone prompt, when they sign in to agency systems. Identity teams enroll each person and keep the rule on.

Identification and Authentication (Organizational Users) | Access to Accounts, Separate Device

Implement multi-factor authentication for remote access to privileged accounts and non-privileged accounts such that:

a. One of the factors is provided by a device separate from the system gaining access; and

b. The device meets Authenticator Assurance Level 2 (AAL) per NIST SP 800-63.

In practice: For remote sign-ins, the second factor comes from a separate device such as a phone or hardware key, not from the laptop being used to connect.

Identification and Authentication (Organizational Users) | Access to Accounts, Replay Resistant

Implement replay-resistant authentication mechanisms for access to privileged accounts with network access.

In practice: Administrators use sign-in methods built to resist replay, such as one-time passcodes or, more strongly, hardware security keys, which also resist phishing, rather than a reusable password alone.

Identifier Management

Manage system identifiers by:

a. Receiving authorization from designated agency officials to assign an individual, group, role, service, or device identifier;

b. Selecting an identifier that identifies an individual, group, role, service, or device;

c. Assigning the identifier to the intended individual, group, role, service, or device; and

d. Preventing reuse of identifiers indefinitely

In practice: Each new person gets a unique user ID from the HR-driven onboarding workflow. An ID is never reused for someone else, and each service or device receives its own identifier.

Identifier Management | Identify User Status

Manage individual identifiers by uniquely identifying each individual as agency-defined characteristic identifying individual status (e.g., Contractor).

(IRS-Defined): Change all default vendor-set or factory-set administrator accounts prior to implementation (e.g., during installation or immediately after installation).

In practice: The identity source carries a worker-type attribute, such as employee or contractor, so every account shows what kind of person it belongs to and reports can be filtered by it.

Authenticator Management

Manage system authenticators by:

a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, service, or device receiving the authenticator;

b. Establishing initial authenticator content for any authenticators issued by the organization;

c. Ensuring that authenticators have sufficient strength of mechanism for their intended use;

d. Establishing and implementing administrative procedures for initial authenticator distribution, for lost or compromised or damaged authenticators, and for revoking authenticators;

e. Changing default authenticators prior to first use;

f. Changing or refreshing authenticators every 90 days for all user accounts and every 366 days for service accounts or when events such as loss, theft or compromise occur;

g. Protecting authenticator content from unauthorized disclosure and modification;

h. Requiring individuals to take, and having devices implement, specific controls to protect authenticators; and

i. Changing authenticators for group or role accounts when membership to those accounts’ changes.

In practice: New credentials are handed out only after the person is verified. Service account passwords sit in a vault and are rotated on a schedule, and leavers have their credentials revoked.

Identification and Authentication (Non-Organizational Users)

Uniquely identify and authenticate non-organizational users or processes acting on behalf of non-organizational users.

In practice: Members of the public who use an agency portal to review a tax account or payment history each sign in with their own credential, so every person is individually identified and nobody shares a login.

Identification and Authentication (Non-Organizational Users) | Acceptance of External Credentials

a. Accept only external authenticators that are NIST-compliant; and

b. Document and maintain a list of accepted external authenticators.

In practice: For its public portal, the agency keeps a written list of the outside credentials it accepts, such as a government sign-in service, and accepts only credentials that conform to NIST SP 800-63.

Identification and Authentication (Non-Organizational Users) | Use of Defined Profiles

Conform to the following profiles for identity management: NIST or FICAM-issued profiles.

(IRS-Defined): Deploy identification and authentication technology consistent with the results of the e-authentication risk analysis.

In practice: When members of the public sign in to an agency portal through a federated credential, the setup follows the identity profiles the requirement names and the agency's e-authentication risk analysis, and the integration team records which application uses which profile.

Re-Authentication

Require users to re-authenticate when switching to a privileged user role.

In practice: Before an administrator switches into a privileged role, the sign-in service asks them to authenticate again, which makes a left-open session harder to misuse.

Identity Proofing

a. Identity proof users that require accounts for logical access to systems based on appropriate identity assurance level requirements as specified in applicable standards and guidelines;

b. Resolve user identities to a unique individual; and

c. Collect, validate, and verify identity evidence.

In practice: HR confirms a new hire's identity first. The onboarding workflow then links the new account to that one verified person and blocks duplicate or unmatched accounts.

Personnel Termination

Upon termination of individual employment:

a. Disable system access within three (3) business days;

b. Terminate or revoke any authenticators and credentials associated with the individual;

c. Conduct exit interviews that include a discussion of information security topics, specifically nondisclosure agreements;

d. Retrieve all security-related organizational system-related property; and

e. Retain access to organizational information and systems formerly controlled by terminated individual.

In practice: When HR records a termination, the leaver workflow disables the person's accounts within three business days and revokes their tokens and credentials.

Personnel Transfer

a. Review and confirm ongoing operational need for current logical and physical access authorizations to systems and facilities when individuals are reassigned or transferred to other positions within the organization;

b. Initiate transfer or when warranted extended reassignment actions within five (5) business days of the formal transfer action;

c. Modify access authorization as needed to correspond with any changes in operational need due to reassignment or transfer; and

d. Notify designated agency personnel within five (5) business days of transfer.

In practice: When someone changes jobs, the mover workflow asks the new manager to confirm which access to keep. Access that is no longer needed is removed.

Session Termination

Automatically terminate a user session after 30 minutes of inactivity.

In practice: The application and endpoint teams set the 30-minute inactivity timeout; identity contributes idle-session and re-sign-in settings on the single sign-on service where the platform supports them, so a returning user has to sign in again.

Use of External Systems

a. Establish terms and conditions, consistent with the trust relationships established with other organizations owning, operating and/or maintaining external systems, allowing authorized individuals to:

1. Access the system from external systems; and

2. Process, store, or transmit organization-controlled information using external systems; or

b. Prohibit the use of non-agency managed external systems.

In practice: The agency decides when staff may connect from outside systems. Identity contributes by letting sign-in rules check whether a device is registered and managed before access is allowed.

Audit Events

a. Identify the types of events that the system is capable of logging in support of the audit function:

1. All accesses or attempts to access an FTI system, including the identity of each user and device;

2. Logoff activities;

3. Activities that might modify, bypass, or negate IT security safeguards;

4. Security-relevant actions associated with processing FTI;

5. User generation of reports and extracts containing FTI;

6. Any interaction with FTI through an application;

7. Password changes;

8. Creation or modification of groups;

9. Privileged user actions;

10. Access to the system;

11. Creating and deleting files;

12. Change of permissions or privileges;

13. Command line changes and queries;

14. Changes made to an application or database;

15. System and data interactions;

16. Opening and/or closing of files; and

17. Program execution activities.

b. Coordinate the event logging function with other organizational entities requiring audit related information to guide and inform the selection criteria for events to be logged;

c. Specify the following event types for logging within the system: agency-defined subset of AU-2a requirements (e.g. Systems capable of required event types relevant to the use or administration of FTI);

d. Provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents; and

e. Review and update the event types selected for logging annually or when there is a system change. Document changes in the SSR.

In practice: The security team decides which events get logged. Identity contributes by turning on logging for sign-ins, permission changes and privileged actions on the identity platform.

Content of Audit Records

Ensure that audit records contain information that establishes the following:

a. What type of event occurred;

b. When the event occurred;

c. Where the event occurred;

d. Source of the event;

e. Outcome of the event; and

f. Identity of any individuals, subjects, or objects/entities associated with the event.

In practice: System owners decide what audit records contain; each identity log line adds what happened, when, where and which named account did it, which helps investigators trace activity.

Audit Review, Analysis and Reporting

a. Review and analyze system audit records weekly for indications of inappropriate or unusual activity and the potential impact of the inappropriate or unusual activity;

b. Report findings to the individual(s) specified within the agency’s incident response procedures; and

c. Adjust the level of audit record review, analysis, and reporting within the system when there is a change in risk based on law enforcement information, intelligence information, or other credible sources of information.

In practice: The security team reviews logs every week for odd activity. Identity logs add sign-in and permission-change records, and alerts flag unusual account behavior for that review.

Audit Generation

a. Provide audit record generation capability for the event types the system is capable of auditing as defined in AU-2a on all systems that receive, process, store, access, protect and/or transmit FTI;

b. Allow SA and ISSO to select the event types that are to be logged by specific components of the system; and

c. Generate audit records for the event types defined in AU-2c that include the audit record content defined in AU-3.

In practice: System owners turn on audit logging; identity contributes by enabling log generation on the identity systems themselves, so account and sign-in events are captured from day one.

Identification and Authentication Policy and Procedures

a. Develop, document, and disseminate to designated agency officials:

1. An agency or organization-level identification and authentication policy that:

(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities and compliance; and

(b) Is consistent with applicable laws, Executive Orders, directives, regulations, policies, standards, and guidelines; and

2. Procedures to facilitate the implementation of the access control policy and the associated access controls;

b. Designate an agency official to manage the development, documentation, and dissemination of the access control policy and procedures; and

c. Review and update the current identification and authentication:

1. Policy every three (3) years (or if there is a significant change); and

2. Procedures every three (3) years (or if there is a significant change).

In practice: The agency's written sign-in policy says who is covered and who owns it. An assessment of the current identity setup helps the policy writers describe what is actually in place.

Device Identification and Authentication

Uniquely identify and authenticate devices before establishing a remote or network connection.

In practice: Laptops and other devices are registered and issued a certificate. The network lets a device connect only when it can show that certificate, and the security team owns the network side.

Service Identification and Authentication

Uniquely identify and authenticate agency-defined system services and applications before establishing communications with devices, users, or other services or applications.

In practice: The application owner and developers decide how services identify themselves. Identity contributes by giving each service its own workload identity rather than a shared password.

Identity Proofing | Supervisor Authorization

Require that the registration process to receive an account for logical access includes supervisor or sponsor authorization.

In practice: The agency sets the registration rules; in the access request workflow, a new account request routes to the supervisor or sponsor, and no account is created until they approve.

Personnel Screening

a. Screen individuals prior to authorizing access to the system; and

b. Rescreen individuals in accordance with agency-defined conditions requiring rescreening but no less than once every five years.

See Section 2.C.3, Background Investigation Minimum Requirements for additional requirements.

In practice: HR owns background screening. The onboarding workflow holds a new hire's access until HR marks screening complete, and a rescreening date can trigger a task for HR.

Access Agreements

a. Develop and document access agreements for organizational systems;

b. Review and update the access agreements at a minimum annually; and

c. Verify that individuals requiring access to organizational information and systems:

1. Sign appropriate access agreements prior to being granted access; and

2. Re-sign access agreements to maintain access to organizational systems when access agreements have been updated or at a minimum annually.

In practice: HR and legal own the access agreement. The onboarding and request workflows can require the person to acknowledge it before access is granted, and the date is recorded.

External Personnel Security

a. Establish personnel security requirements, including security roles and responsibilities for external providers;

b. Require external providers to comply with personnel security policies and procedures established by the organization;

c. Document personnel security requirements;

d. Require external providers to notify designated agency personnel of any personnel transfers or terminations of external personnel who possess organizational credentials and/or badges, or who have system privileges within three (3) business days; and

e. Monitor provider compliance with personnel security requirements.

In practice: The agency sets security terms for providers; identity contributes sponsored contractor and vendor accounts, each with an end date, that are turned off when the contract ends.

System Use Notification

a. Display a warning banner to users before granting access to the system that provides privacy and security notices consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and state that:

1. Users are accessing a U.S. Government System;

2. System usage may be monitored, recorded, and subject to audit;

3. Unauthorized use of the system is prohibited and subject to criminal and civil penalties; and

4. Use of the system indicates consent to monitoring and recording;

b. Retain the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the system; and

c. For publicly accessible systems:

1. Display system use information warning banner before granting further access to the publicly accessible system;

2. Display references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities and

3. Include a description of the authorized uses of the system.

Device Lock

a. Prevent further access to the system by initiating a device lock after 15 minutes of inactivity; requiring the user to initiate a device lock before leaving the system unattended; and

b. Retain the device lock until the user reestablishes access using established identification and authentication procedures.