← All insights

Firefighter access that auditors trust

Emergency access is one of the most powerful and least governed parts of an SAP estate. Done badly, it's a standing audit finding. Done well, it's an invisible safety net. The difference is design, not tooling.

Every SAP landscape needs a way to act fast when something breaks. A payment run fails at month-end, an interface stalls, a configuration needs an urgent fix, and the person who can solve it needs elevated access right now. That's what emergency, or "Firefighter," access exists for: temporary, privileged rights granted for a specific situation, then withdrawn.

The concept is sound. The execution is where it goes wrong. Emergency access is, by definition, powerful access used outside normal controls, which makes it the first thing auditors probe and the last thing most teams have properly under control.

Why it becomes a finding

The same failure patterns appear again and again:

• It stops being temporary. Access granted for a go-live is still active a year later. The "emergency" became permanent, and now sits as standing privileged access no one is watching.
• No one reviews what was done. The access is logged, but the logs are never read. A control that captures evidence but no one reviews is not a control, it's an archive.
• The wrong people approve. Requests are waved through by whoever is available, not by someone who can judge whether the access was appropriate.
• It's broader than it needs to be. Instead of access scoped to the problem, the Firefighter ID carries near-unlimited rights "just in case", turning every use into a wide-open window.

Auditors don't object to emergency access. They object to emergency access that no one can prove was justified, time-boxed and reviewed.

What good looks like

Well-designed Firefighter access rests on a few principles, none of which require heroic effort once they're built in.

Scope it to the job

Emergency access should be powerful enough to fix real problems and no more. That usually means a small set of purpose-built Firefighter roles aligned to genuine scenarios, finance, basis, master data, rather than one all-powerful ID. Scoped access shrinks the blast radius of every session.

Make it time-boxed by default

Access should expire automatically. The default state is "off"; a request switches it on for a defined window; it switches itself off again. Permanence should require a deliberate, visible decision, never the absence of one.

Tie every session to a reason and a review

The point of emergency access is accountability after the fact. Each session should carry a stated reason, and produce a log of what was actually done that a named, independent reviewer checks promptly. The review is the control. Everything else is plumbing.

Separate the requester, approver and reviewer

The person who uses the access shouldn't approve their own request or review their own session. Keeping those roles distinct is what lets you stand behind the process when it's challenged.

The quiet test

There's a simple way to know whether emergency access is genuinely under control: pick a session from three months ago at random and try to answer four questions. Who used it? Why? What did they do? Who confirmed it was appropriate, and when? If those answers come back quickly and credibly, the design is working. If they require an archaeology project, the finding is already written.

Privileged access will always be a concentration of risk; that's the nature of it. But it doesn't have to be a recurring audit problem. With scoped roles, automatic expiry, a reason attached to every session and a review that actually happens, emergency access becomes what it was meant to be, a safety net that's there when you need it and accountable every time it's used.