Security & GRCadvanced

Emergency Access Governance: SoD, Break-Glass Design and Accountability (Part 5)

Key takeaway

Design emergency access as a controlled break-glass mechanism with least privilege, risk analysis, independent approval/review, short validity, incident linkage and metrics that prevent EAM from becoming a permanent SoD bypass.

Explanation

📌 KEY POINTS
✅ EAM deliberately allows privileged access that normal SoD design prohibits — that makes governance stronger, not weaker, if it's built right.
⚠️ Emergency access used for predictable monthly tasks is a red flag — it means a normal role/process should exist instead.
💡 A severe GRC/identity outage still needs an emergency path — break-glass accounts need even stronger custody and dual control.

━━━━━━━━━━━━━━━━━━━━
▶ 1. BUILD ROLES AROUND REAL NEED

Decide which high-risk activities truly need emergency access
Build Firefighter roles/IDs around those specific activities, not broad superuser access
Risk-analyze the emergency role so Owners understand what conflicts it introduces

━━━━━━━━━━━━━━━━━━━━
▶ 2. REQUEST DISCIPLINE

Tie every request to an incident/change/business need, valid only for the required window
Emergency approval can be expedited but must still be attributable
Post-use Controller review compensates for the temporary privilege — and should be independent

━━━━━━━━━━━━━━━━━━━━
⚠️ 3. METRICS THAT REVEAL ABUSE

Frequent Firefighter use, repeated reasons, long sessions, overdue log reviews, permanent assignments, emergency access for predictable monthly tasks
Any of these means a normal role/process should be designed instead

━━━━━━━━━━━━━━━━━━━━
▶ 4. BREAK-GLASS RESILIENCE

During a severe identity/GRC outage, an offline emergency-account procedure may be needed
Requires stronger credential custody, dual control, monitoring, and post-event reconciliation — normal EAM workflow may be unavailable

✅ CHECKPOINT: name three usage patterns that signal EAM is being used as a workaround, not an exception.

Real project scenario

A finance support analyst used Firefighter every month-end to run the same reconciliation transaction. EAM technically logged it, but monthly predictable use was not an emergency. Security created a narrow normal role with required approval and removed the recurring Firefighter dependency.

Common mistakes

Calling recurring support an emergency.
Keeping Firefighter assignments permanently active.
Using SAP_ALL-style access when a narrow emergency role is possible.
Ignoring frequency/duration metrics.
Having no contingency for GRC/identity outages.

Best practices

Analyze emergency roles for risk.
Minimize privilege scope.
Expire assignments quickly.
Track frequent/recurring use.
Maintain a governed offline break-glass contingency.

Interview angle

Explain EAM as a compensating break-glass control, not an SoD exception with no oversight. Strong answers include least privilege, incident linkage, expiry, independent review and usage metrics.

Practice this lesson

Quick check

1. Scenario — A finance support analyst used Firefighter every month-end to run the same reconciliation transaction. For the lesson "Emergency Access Governance: SoD, Break-Glass Design and Accountability", which response shows the strongest architecture and production judgment?

2. What is the primary purpose of Emergency Access Management (EAM) within SAP GRC Access Control?

3. What does a "reason code" represent in the context of Emergency Access Management configuration?

Interview questions

1. You are the senior consultant/architect responsible for Emergency Access Governance: SoD, Break-Glass Design and Accountability. The project situation is: A finance support analyst used Firefighter every month-end to run the same reconciliation transaction. 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. Using this SAP project situation — An operations user needs temporary table-maintenance access during a production incident — explain Emergency Access Management Fundamentals. What should happen, which concepts or process steps matter, and what common mistake would you avoid?

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.