Firefighter Access: EAM Without the Chaos

Emergency access management addresses a real operational problem: production systems sometimes need access granted quickly that cannot go through the normal provisioning process. A basis admin needs to diagnose a critical incident. A security team member needs to review production data during an audit. The normal process takes days. The incident needs resolution in hours.

Without a defined emergency access process, these situations are resolved by informal workarounds — sharing passwords, temporarily assigning SAP_ALL, or using generic admin users with no individual accountability. All of these create audit findings. EAM is the defined alternative.

What Emergency Access Management Is

EAM is a controlled process for granting temporary elevated access to production systems, with logging of all activity performed during the access period, followed by mandatory review of those logs.

The key components are: a request and approval workflow (who approved the access, when, and why), a time-limited access mechanism (the access expires automatically or is revoked after the incident), activity logging (every transaction and change made during the emergency access session is recorded), and log review (a named reviewer examines the logs after each use).

Without all four components, it is not EAM — it is informal elevated access with extra documentation.

The Firefighter Concept

The term "Firefighter" comes from SAP GRC Access Control's Emergency Access Management module. The concept is that a named Firefighter ID — a shared user account with elevated access — is checked out by an individual user for the duration of an incident, then checked back in. All activity performed under the Firefighter ID is logged and attributed to the individual who checked it out.

The Firefighter ID itself has no password known to users — it is checked out through a controlled mechanism, not logged into directly. This separation is important for audit purposes: the logs show who used the account and when, without giving any individual standing access.

With GRC Access Control

SAP GRC Access Control provides the Firefighter module as a complete EAM solution. The workflow covers request, approval by a named owner, time-limited checkout, session logging, automatic log delivery to reviewers, and sign-off tracking.

If your organisation has GRC Access Control licensed and deployed, use the Firefighter module for all emergency access. Do not create informal alternatives that bypass GRC logging — they create gaps in the audit trail even if the access itself was legitimate.

Firefighter IDs should be maintained with the minimum access required for the scenarios they are designed to address. A Firefighter ID for BASIS incident response does not need access to financial posting transactions. Scope the access to the incident type.

Without GRC: Manual Approaches

Many organisations have production SAP systems without GRC. Emergency access is still possible and auditable without it, but requires more procedural discipline.

The most common manual approach uses a dedicated emergency access role and a controlled account assignment process. The steps: the requester submits a formal request (email or ticketing system) with the business justification and expected duration; a named approver (typically the system owner or security lead) approves; a basis admin assigns the emergency role with an account validity end date in SU01; at the end of the period the access is revoked; and the approver reviews the activity log from SM20 or the STAD transaction.

The weakness of the manual approach is that it depends entirely on process discipline — there is no technical enforcement of the review step. Build the review step into your incident closure checklist and treat skipping it as a process non-compliance.

Log Review Requirements

The value of EAM depends entirely on the log review. An emergency access log that is never reviewed is not EAM — it is documentation of a control that does not function.

Log review should happen within 24 hours of access revocation for critical systems, and within 5 business days for all others. The reviewer should be someone independent of the person who used the emergency access — not their direct manager, and not another member of the basis team reviewing each other's access.

What to look for in a review: transactions outside the stated scope of the incident, data downloads or exports, changes to user authorizations or security configuration, and access to sensitive business data unrelated to the incident. Flag anything that does not match the stated justification.

The Audit Trail

For each emergency access event, the audit trail should include: the original request with business justification, the approval record with approver identity and timestamp, the access assignment record from SU01, the activity log from SM20 or STAD, and the review sign-off.

Keep these records for the duration required by your regulatory obligations — typically a minimum of three years for SOX-covered systems, longer for others. The audit trail for EAM events is one of the first things external auditors look for when reviewing privileged access controls.

Common EAM Failures

The most common failure is emergency access that never gets reviewed. The access is granted, the incident is resolved, the ticket is closed, and the log review never happens. Automate the review reminder wherever possible.

The second failure is permanent emergency access — Firefighter IDs or emergency roles that are assigned indefinitely rather than time-limited. Audit your emergency access users quarterly and revoke any that have not been used or that have exceeded their intended scope.

The third failure is scope creep in the Firefighter IDs themselves. Over time, access is added to accommodate new incidents. Nobody removes the access added for old incidents. The Firefighter ID becomes a permanent super-user with unreviewable historical access accumulation. Review the access in your Firefighter IDs annually.

> Editorial note: EAM requirements vary significantly by regulatory framework and audit standard. SOX, GDPR, and ISO 27001 each impose different specific requirements. Validate your EAM design with your compliance team and external auditors.