Emergency Access Management: Firefighter IDs, Owners and Controllers (Part 2)
Understand EAM roles clearly: the Firefighter uses temporary elevated access, the Firefighter ID or role carries the privilege, the Owner governs assignment, and the Controller independently reviews activity logs.
Explanation
📌 KEY POINTS
✅ Firefighter (who needs access), Owner (who's responsible for the ID/role), Controller (who reviews and signs off) — three distinct roles.
⚠️ A Firefighter should not be their own Controller for high-risk activity — independence is the whole point.
💡 EAM is not an unlimited superuser mechanism — scope it to real support duties, time-limit it, risk-analyze it.
━━━━━━━━━━━━━━━━━━━━
▶ 1. THE THREE ROLES
- Firefighter — the person who needs emergency access (an ID in ID-based EAM, or an emergency role in role-based models)
- Owner — responsible for the Firefighter ID/role and its assignments
- Controller — reviews activity logs, approves/signs off per policy
━━━━━━━━━━━━━━━━━━━━
⚠️ 2. INDEPENDENCE MATTERS
- A Firefighter should not be their own Controller for high-risk activity
- Owners should understand exactly what privilege the ID contains and who can request it
━━━━━━━━━━━━━━━━━━━━
▶ 3. TWO ARCHITECTURES
- Centralized firefighting — GRC provides the central access console
- Decentralized — users access plugin systems directly while GRC maintains assignments/reporting
- Exact behavior depends on configured version
━━━━━━━━━━━━━━━━━━━━
⚠️ 4. WHAT IT'S NOT
- Not an unlimited superuser mechanism
- IDs/roles should be scoped to real support duties, time-limited, and risk-analyzed
- Permanent broad access hidden inside a Firefighter ID defeats the control entirely
✅ CHECKPOINT: explain why a Firefighter reviewing their own logs breaks the control.
Real project scenario
A Basis team used one Firefighter ID with SAP_ALL for every incident, owned and reviewed by the same team lead. Audit could not demonstrate independent review or least privilege. The design was split into role-specific emergency IDs with business/security Owners and independent Controllers, plus expiry and log-review SLAs.
Common mistakes
- Using one all-powerful Firefighter ID for every support case.
- Making Owner, Controller and Firefighter effectively the same control person.
- Leaving assignments open-ended.
- Treating Firefighter as replacement for normal admin roles.
- Failing to inventory what each emergency ID/role actually contains.
Best practices
- Scope emergency IDs by support need.
- Separate assignment ownership from log review.
- Use time-bound assignments.
- Review privilege content periodically.
- Keep centralized/decentralized architecture documented.
Interview angle
Define Firefighter, Firefighter ID, Owner and Controller accurately. Strong answers mention independent log review and centralized/decentralized EAM models.
Practice this lesson
Quick check
1. Scenario — A Basis team used one Firefighter ID with SAP_ALL for every incident, owned and reviewed by the same team lead. For the lesson "Emergency Access Management: Firefighter IDs, Owners and Controllers", which response shows the strongest architecture and production judgment?
2. In the standard EAM setup, which role is responsible for assigning firefighter IDs or roles to the appropriate firefighter users and owners?
3. After a firefighter session ends, whose responsibility is it to review the generated activity log and confirm the actions taken were appropriate?
Interview questions
1. You are the senior consultant/architect responsible for Emergency Access Management: Firefighter IDs, Owners and Controllers. The project situation is: A Basis team used one Firefighter ID with SAP_ALL for every incident, owned and reviewed by the same team lead. How would you assess the design, identify the highest-risk failure modes, and define the evidence required before approving it for production?
Answer it in your own words first, then compare.
2. You are the senior consultant/architect responsible for Troubleshooting EAM: Synchronization, Missing Logs and Connector Problems. The project situation is: Firefighter sessions worked after an S/4 upgrade, but Controllers received no logs. How would you assess the design, identify the highest-risk failure modes, and define the evidence required before approving it for production?
Answer it in your own words first, then compare.
Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.
More lessons in this topic
- Emergency Access Governance: SoD, Break-Glass Design and Accountability (Part 5)
- Firefighter Logging and Log Review: Building Audit Evidence (Part 4)
- Requesting, Assigning and Using Emergency Access (Part 3)
- SAP Emergency Access Management Tutorial (Part 1)
- Troubleshooting EAM: Synchronization, Missing Logs and Connector Problems (Part 6)