Security & GRCadvanced

Requesting, Assigning and Using Emergency Access (Part 3)

Key takeaway

Operate emergency access as a formal sequence: documented request and reason, owner approval, time-bound assignment, controlled Firefighter session, and post-use review rather than informal credential sharing.

Explanation

📌 KEY POINTS
✅ Request → approve → use → review — every stage produces evidence for the next.
⚠️ Never share passwords for emergency IDs outside the supported EAM design — that destroys individual accountability.
💡 Long permanent Firefighter assignments weaken the "emergency" nature of the control — design a proper least-privilege role instead.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE REQUEST

Explain the incident/change requiring elevated privilege, which system, expected activities, how long access is needed

━━━━━━━━━━━━━━━━━━━━
▶ 2. APPROVAL AND USE

Business process owner or configured EAM owner approves/rejects
Firefighter obtains/uses the ID or role through the supported mechanism
A meaningful reason code/description matters — it becomes part of the audit review later

━━━━━━━━━━━━━━━━━━━━
⚠️ 3. TIME-BOXING

Assignments should be time-limited
Long permanent assignments weaken the control — recurring support work needs a proper least-privilege role instead

━━━━━━━━━━━━━━━━━━━━
▶ 4. AFTER THE SESSION

Logs must be collected and reviewed against the original request reason
Investigate any unexpected privileged action

⚠️ 5. THE HARD RULE

Never share emergency-ID passwords outside the supported EAM design — credential sharing destroys individual accountability, even if the ID itself is logged

✅ CHECKPOINT: name the four stages of an emergency-access session, in order.

Real project scenario

A production outage required urgent table/configuration access. Instead of giving the engineer a permanent admin role, the engineer requested a Firefighter ID for two hours with incident number and planned actions. After restoration, the Controller reviewed transactions and changes against the incident. Access expired automatically.

Common mistakes

Sharing emergency-ID passwords manually.
Giving indefinite assignments.
Using vague reasons such as "support."
Skipping owner approval because the incident is urgent.
Failing to review actual activity after the incident.

Best practices

Link requests to incident/change records.
Require specific intended actions.
Keep validity short.
Use supported login/session mechanisms.
Review activity against the original purpose.

Interview angle

Describe the full EAM lifecycle from request to log review. Strong answers emphasize documented purpose, time-bound assignment and accountability rather than only how to launch Firefighter.

Practice this lesson

Quick check

1. Scenario — A production outage required urgent table/configuration access. For the lesson "Requesting, Assigning and Using Emergency Access", which response shows the strongest architecture and production judgment?

2. How does obtaining access through Emergency Access Management typically differ from requesting elevated access through the standard Access Request process in GRC Access Control?

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 Requesting, Assigning and Using Emergency Access. The project situation is: A production outage required urgent table/configuration access. 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.

Practice more with Interview AI →

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.