SAP Emergency Access Management Firefighter ID: Setup, Use, and Log Review

Emergency access gives a user temporary, controlled access to functions that sit outside their normal role. In SAP Governance, Risk, and Compliance, the firefighter ID provides the technical identity for that work, while the assigned firefighter user remains accountable for the activity.

A reliable process connects four controls: a defined emergency reason, a time-bound assignment, complete activity logging, and an independent review. This guide focuses on operating that process and investigating common gaps in SAP Access Control EAM.

01Understand the firefighter ID model

A firefighter ID is a privileged user ID used for emergency work. The firefighter logs on through the configured EAM launch path, performs the approved task, and leaves an application log associated with the session. The firefighter ID can be assigned centrally or locally, depending on the EAM design and the connected system landscape.

The firefighter user is the person who performs the work. The firefighter ID is the controlled technical identity used during the session. A firefighter controller is responsible for reviewing the recorded activity. Keeping these responsibilities separate supports an independent review trail.

EAM belongs within the broader SAP security and governance operating model. Use the SAP security and GRC overview to align emergency access with access governance, audit evidence, and ownership boundaries.

02Prepare the EAM control design

Start with an inventory of emergency scenarios. Each scenario should identify the business process, affected system, required transaction or application scope, approving owner, expected duration, and reviewer. Typical scenarios include production incident resolution, period-end recovery, urgent master-data correction, and controlled configuration repair.

Create a separate firefighter ID for each appropriate scope. A narrowly scoped ID makes log review more meaningful and limits the impact of a compromised credential. Use naming conventions that identify the system purpose without exposing passwords or operational secrets.

Define the following before assigning access:

• Firefighter ID owner and system owner
• Firefighter users and their approval path
• Controller or reviewer for each assignment
• Valid reason codes and required comments
• Maximum assignment duration
• Notification and escalation rules
• Log-retention and evidence requirements

Review the design against segregation-of-duties analysis. Emergency access can support a controlled exception process, while the underlying conflict and its compensating controls remain visible. The SAP segregation of duties basics article provides useful context for separating preventive controls from emergency procedures.

03Configure a firefighter ID assignment

Use SAP Access Control administration to create or register the firefighter ID, connect it to the target system, and assign the appropriate owner. Validate the connector and target-system relationship before opening the ID for operational use.

For every firefighter user, record the assignment scope and approval evidence. Configure the controller who receives the log for review. Where the process uses a central assignment, confirm that the central EAM path reaches the intended target system. Where it uses a local assignment, confirm the local assignment and local controller in the target system.

Use least privilege for the firefighter ID. Emergency access requires elevated capability, but the ID still benefits from a focused role design. Separate IDs for database administration, financial correction, logistics recovery, or application support when those activities have different owners and reviewers.

Use the SAP GRC Access Control overview when mapping EAM to access requests, risk analysis, provisioning, and review activities.

04Run a controlled firefighter session

Before the session begins, confirm the incident or change reference, approval, target system, firefighter user, firefighter ID, and expected end time. Select a precise reason code and enter a useful comment. A good comment states the business impact, the action required, and the reference used to authorize the work.

During the session, keep the work within the approved scope. Record important values before and after a change, attach supporting evidence to the incident or change record, and avoid unrelated investigation under the same ID. A session with a clear operational boundary is easier to review than a session that combines several incidents.

At the end of the work, close the session and confirm that the assignment has ended. The EAM log should identify the firefighter user, firefighter ID, start and end times, reason, target system, and recorded activity. The technical log and the incident record should tell the same operational story.

05Review firefighter logs

The controller should review each log against the approved reason and the related incident or change. Check the session identity, timestamps, target system, transactions or applications used, changed objects, and before-and-after values where available.

Use a structured review sequence:

1. Confirm the assignment and approval existed before the work began.
2. Match the reason code and comment to the incident or change reference.
3. Compare the session time with the approved window.
4. Examine high-impact actions and changed values.
5. Confirm that the activity supports the stated emergency purpose.
6. Record the review decision, reviewer, date, and follow-up action.

Classify exceptions consistently. A missing comment, late review, activity outside the approved window, unexpected transaction, or unexplained data change requires evidence collection and owner follow-up. Preserve the original log and add the explanation to the review record rather than overwriting the event.

For broader audit-log operating practices, see SAP security audit log basics. This helps connect EAM review with the wider investigation process for authentication, authorization, and system activity.

06Troubleshoot common EAM failures

The firefighter ID cannot be selected: verify that the ID is registered in the intended connector, the assignment is active, the user is permitted to use it, and the target system is available. Check the assignment dates and the controller configuration.

The session starts but no useful log appears: verify the logging configuration, target-system connection, user mapping, and time synchronization. Confirm that the activity was performed through the EAM-controlled path and that the log collector can reach the target system.

The controller receives no review item: check the controller assignment, notification configuration, workflow status, and job monitoring. Confirm that the session closed successfully and that the review interval has elapsed where scheduled processing is used.

The log contains unexpected activity: preserve the original evidence, suspend further use of the affected firefighter ID when appropriate, compare the activity with the incident record, and escalate to the security and process owners. Review the ID's role scope and recent assignment history before restoring normal use.

The reviewer cannot establish accountability: reconcile the EAM assignment, session identity, target-system user, timestamps, and incident reference. Then document the evidence gap and apply the organization’s exception process.

07Operate EAM as a recurring control

Treat EAM as an operating control rather than a one-time configuration. Review firefighter IDs, owners, users, controllers, role scope, connector status, reason codes, and retention settings on a scheduled basis.

Track practical measures such as open assignments, overdue reviews, sessions without a valid reference, repeated use of the same emergency scenario, and firefighter IDs with excessive scope. Trends often reveal process weaknesses before an audit identifies them.

Include EAM in joiner, mover, and leaver procedures. Remove departed users promptly, update controllers when responsibilities change, and reassess assignments after organizational or system changes. Keep the process aligned with SAP user access review basics so periodic access review and emergency-access review reinforce each other.

A mature firefighter process makes urgent work possible while preserving accountability. The strongest implementation combines narrow IDs, clear approvals, meaningful reason codes, complete logs, timely independent review, and documented exception handling.