Firefighter roles sit at an uncomfortable intersection in SAP security. They exist precisely because normal authorizations are not enough for certain situations: a production incident at 2 a.m., a finance closing with a blocked transaction, a rare business event that nobody planned for. In those moments, someone needs elevated access, fast. At the same time, Firefighter access grants exactly the kind of broad privileges that SoD and least-privilege principles try to prevent.

A well-designed Firefighter process resolves this tension. A poorly designed one becomes a permanent bypass of your security controls, and it is exactly the finding external auditors will highlight in their report.

This article covers how to design Firefighter roles that survive audit scrutiny, how to operate them in practice, and the most common mistakes to avoid.

What Firefighter Access Actually Is

SAP Emergency Access Management (EAM), often called "Firefighter," is a GRC Access Control module that allows users to temporarily assume a pre-defined high-privilege role for a bounded time window. The typical flow is:

  1. A user needs emergency access beyond their regular role.
  2. They request (or are pre-assigned) a Firefighter ID.
  3. They log on with the Firefighter ID, which carries the elevated authorizations.
  4. All activity during the Firefighter session is logged.
  5. After the session, a reviewer (typically the Firefighter owner or an independent reviewer) examines the log and approves or escalates.

Firefighter is not a specific SAP role type. It is a governance process around temporarily elevated access, with logging and review built in.

Firefighter Role Scoping: Narrow Beats Broad

The single biggest design decision is how broadly you scope each Firefighter role. The instinct is often to create one or two all-powerful Firefighter roles that cover any emergency. This is the wrong instinct for two reasons: it undermines the audit trail (you cannot tell what someone was supposed to be doing), and it amplifies risk (one compromised Firefighter ID gives an attacker near-total access).

Better practice: scope Firefighter roles by functional area and incident type. Common scoping patterns:

  • FI Production Support Firefighter: access needed to resolve financial posting errors, blocked documents, period-end issues.
  • MM Emergency Procurement Firefighter: access to create an emergency vendor or PO outside normal workflow.
  • HR Incident Firefighter: access to correct employee master data issues.
  • Basis / System Administration Firefighter: access for technical incidents, transport issues, system stops.
  • Security Incident Firefighter: access for responding to security incidents specifically, typically owned by the security team.

Each Firefighter role has a defined owner, a defined use case, and the minimum authorizations needed for that use case. This scoping gives auditors a clear map of who can do what in emergencies, and why.

Ownership and Accountability

Every Firefighter role needs a named business owner, distinct from the user who holds the Firefighter ID. This owner is accountable for:

  • Approving (or pre-approving) Firefighter sessions.
  • Reviewing the log after each use.
  • Periodically reviewing the role's scope and user assignments.
  • Escalating suspicious activity or scope creep.

The owner should be in the line of business the Firefighter supports, not in IT or security. For the FI Production Support Firefighter, the owner is a senior finance manager; for the MM Emergency Procurement Firefighter, it is a senior procurement or supply chain manager.

Separating ownership from execution is a structural SoD control: the people who use Firefighter cannot also sign off on its use.

Logging and Review: The Control That Makes Firefighter Work

Firefighter access without log review is not a control; it is a bypass. SAP GRC EAM logs the transactions executed during a Firefighter session, including change documents where applicable. The review process should:

  • Happen within a defined SLA after each session (typically 24–48 hours).
  • Compare actual activity to the stated justification.
  • Flag activity outside the scope of the stated emergency.
  • Be signed off by the role owner (or a reviewer who is not the Firefighter user).
  • Retain evidence for the audit period defined by your compliance framework.

Review fatigue is the biggest operational risk. If your Firefighter process generates many sessions per week with vague justifications and rubber-stamp reviews, auditors will eventually notice. Two remedies: reduce the frequency of use (often this means fixing root-cause authorization gaps in regular roles), and automate the review workflow with clear escalation triggers.

Firefighter and SoD: How They Interact

Firefighter roles almost always contain SoD-conflicting combinations. That is inherent: the point of the role is to enable tasks that regular SoD rules prevent.

The risk is not that Firefighter grants SoD-conflicting access. The risk is that Firefighter becomes a way to perform SoD-conflicting work as a matter of routine, turning emergency access into a permanent workaround.

Indicators that Firefighter is being misused as a permanent bypass:

  • High frequency of use by the same user.
  • Use without a specific incident ticket or justification.
  • Use for routine period-end or month-end activities (which should be addressed through proper role design, not Firefighter).
  • Log reviews approved without substantive check.

Periodic analysis should correlate Firefighter usage patterns with SoD conflicts in the regular role catalogue. If a user holds a regular role with an SoD conflict mitigating control that assumes "this user does not perform activity X," but Firefighter logs show them performing activity X frequently, the mitigating control is broken.

MTC Skopos supports analysis that combines regular role assignments with Firefighter usage to surface exactly this type of inconsistency.

S/4HANA Considerations

On S/4HANA, Firefighter design follows the same principles but operates in a slightly different landscape:

  • Business roles in S/4HANA introduce new authorization objects and Fiori apps that need Firefighter coverage.
  • Cloud deployments (Rise with SAP, Grow with SAP) may offer different Emergency Access options depending on the edition.
  • Integration with identity providers (Azure AD, SAP IAS) changes how Firefighter ID assignment is provisioned and logged.

An S/4HANA migration is the best opportunity to redesign Firefighter roles from scratch, rather than porting existing ECC Firefighter designs. See our S/4HANA migration guide for the full authorization redesign playbook.

Common Audit Findings on Firefighter

External auditors look for a consistent set of weaknesses. The most common ones:

  1. No named business owner, or ownership sitting inside IT rather than the business.
  2. Overly broad roles, often a single "super Firefighter" covering all modules.
  3. Missing log review or log review happening months after sessions.
  4. No SLA on review or reviews performed by the same user who requested the access.
  5. Permanent or unlimited-duration Firefighter assignments to specific users.
  6. No pre-approval workflow for Firefighter use, or a workflow that is routinely bypassed.
  7. Firefighter usage patterns inconsistent with stated use cases (for example, Firefighter used weekly for routine tasks).
  8. No retention of review evidence for the audit period.

Each of these becomes a specific audit finding with required remediation. Addressing them preventively, as part of Firefighter design and operational governance, is much cheaper than remediating them under audit pressure.

How MTC Helps

Our work on Firefighter typically covers:

  • Firefighter role catalogue design aligned with your SAP landscape and risk appetite.
  • Process design for request, approval, logging and review workflows.
  • Owner definition and training in the business lines.
  • Integration with SAP GRC Access Control, or configuration of alternative emergency access patterns for organizations without GRC.
  • Usage analytics using MTC Skopos to correlate Firefighter patterns with broader SoD exposure.
  • Audit readiness and remediation of existing Firefighter audit findings.

For large GRC implementation programs, we partner with leading global audit, risk and technology consulting firms to deliver at scale, while keeping a Swiss-based senior team accountable for the security and authorization outcomes.

Based in Geneva, we help Swiss organizations design Firefighter processes that pass audit and stay workable day-to-day. Contact us to discuss your emergency access model.

Frequently Asked Questions

What is an SAP Firefighter role?

An SAP Firefighter role is a temporary, high-privileged access assignment that allows a user to perform emergency tasks beyond their normal authorizations. The concept is part of SAP GRC Emergency Access Management (EAM) and is used for incident resolution, production support, and other time-limited scenarios where regular roles are insufficient.

How should SAP Firefighter roles be designed?

Well-designed Firefighter roles are scoped to specific use cases (for example, FI incident resolution, MM emergency vendor creation), owned by a named business owner, time-limited, fully logged, and reviewed after each use. Generic all-powerful Firefighter roles are a significant audit finding risk.

What is the difference between Firefighter and SAP_ALL?

SAP_ALL grants unrestricted access and should never be assigned to end users in production. Firefighter assigns elevated but scoped access for a limited time window, with mandatory logging, justification and post-use review. Firefighter is auditable; SAP_ALL is not.

Do Firefighter roles create SoD conflicts?

Firefighter roles almost always contain access combinations that would be SoD conflicts if held permanently. This is why the compensating controls (pre-approval, logging, session review, time limit) are essential. Without them, Firefighter becomes a backdoor that defeats the SoD control framework.