Lesson 3 of 5
Emergency access
10 min
Listen to this lesson
Some work cannot wait for a request cycle: a production job fails during the period-end close, a corrupt record blocks a payment run, a cutover step needs a privileged correction at 3 a.m. Without a controlled process, people solve these problems with shared superuser accounts or permanent broad roles, which auditors rightly flag. Emergency access management (EAM) gives a controlled alternative: elevated access when it is genuinely needed, with every action logged and reviewed.
The parts of emergency access
The firefighter checks out the ID to open a session in the target system, typically giving a reason and a short description of the planned activity. The session runs under the firefighter ID, not the person's own user, but the log ties it to the person. When the session ends, the log is collected and sent to the controller, who reviews it and either confirms it or raises questions. Organizations configure this in different ways, including ID-based firefighting (separate firefighter users) and role-based firefighting (an emergency role temporarily on the person's own user); check which approach your Access Control configuration uses before designing reviews around it.
Designing firefighter IDs
- Scope each ID to a purpose: finance support, logistics support, Basis, security administration. One all-powerful ID makes every review harder and every misuse easier.
- Keep the firefighter list short: only people who are actually called in emergencies, reviewed by the owner.
- Choose independent controllers: the controller must not be the firefighter, and should understand the business area well enough to judge the log.
- Set review deadlines: logs reviewed within a few working days, with escalation if not.
- Never allow normal work through EAM: repeated use for the same task means a role is missing.
Reviewing the log
A controller's review answers three questions: did the activity match the stated reason, was anything done beyond it, and was any change appropriate and supported? The log is only useful if the controller reads it with the ticket or incident beside it. Contoso's rule, agreed between Nadia and Dan, is that every finance firefighter session must reference an incident, and the controller's sign-off on the log is stored with that incident.
- 02:40IncidentThe payment run for company code 1710 stops on a corrupt supplier record during month-end.
- 02:55Check-outSam checks out the finance support firefighter ID with the incident number as the reason.
- 03:20Fix and log offThe record is corrected; the session ends; the log is collected.
- Day 1–3Controller reviewDan's delegate compares the log with the incident and signs off, or queries an unexpected change.
Emergency access does not replace the system's own protections. Standard users such as SAP* and DDIC stay locked down and are not used as emergency accounts; a firefighter ID exists precisely so that nobody needs to share a powerful standard user. Sam's team checks in each quarter that firefighter IDs cannot be used to log on directly outside a checked-out session, and that the list of firefighters still matches the people on call.
What would you do?
Reviewing a month of firefighter logs, the finance controller notices that one AP team member checked out the finance support ID eleven times to post the same type of correction entry. Each session is properly logged and justified. What should happen?
- EAM provides temporary elevated access with every action logged.
- Firefighters check out IDs; owners approve who may use them; controllers review the logs.
- Scope IDs by purpose, keep firefighter lists short and controllers independent.
- Controllers compare logs with the incident and sign off within a deadline.
- Repeated use for the same task signals a missing role, not a healthy process.
Check your understanding · not graded
Lesson check
1. In emergency access management, who reviews the log of a firefighter session?
2. What does the firefighter owner do?
3. Why should firefighter IDs be scoped by purpose rather than one ID for everything?
4. What makes a controller's log review meaningful?