Buyer guide

SAP emergency access: a buyer acceptance checklist

SAP emergency access management governs temporary privileged work when normal authorizations are insufficient. The buying decision is more specific than choosing a general security suite: which identity performs the work, who approves the exception, when access ends, and whether a reviewer can reconstruct the activity afterward. An S/4HANA migration is a useful point to reassess that process, but does not by itself require replacing an existing control.

This guide helps a SAP security lead define requirements before requesting product demonstrations. It provides an acceptance checklist, migration questions and a worksheet for comparing proposals. It is based on public documentation and editorial analysis; no hands-on product testing or vendor confirmation was performed. The detailed requirements below are proposed tests, not claims that a particular product passes them.

Establish the native baseline

The SAP Access Control 12.0 SP31 Emergency Access configuration guide, dated September 23, 2025, distinguishes ID-based and role-based firefighting. It also describes decentralized access during governance-system unavailability, with dependencies for collecting and reviewing logs afterward. These are version-specific configuration statements, not a guarantee for every SAP deployment. Assignment validity should not be mistaken for demonstrated termination of an already active session.

Decide what is actually being replaced

A working SAP Access Control installation belongs in the shortlist as a retain-or-upgrade option. SAP’s published GRC strategy describes continued investment and an upgrade path for HANA-based customers without a new SKU purchase. That is not a promise of zero migration, infrastructure or consulting costs. Entitlements, database changes and supported releases need an individual check.

A buyer should identify the failing control before comparing products. Slow approvals, missing activity records, unreviewed sessions and difficult role maintenance are different problems. A new interface might help reviewers while leaving the underlying logging problem unresolved. Conversely, repairing reviewer ownership or connector configuration could address an issue without adding another platform.

Separate three decisions in the evaluation record: retain and improve the existing system, supplement it with another control, or replace it. For each option, name the system responsible for granting access, the system responsible for recording activity, and the owner who closes review exceptions. A split design needs explicit reconciliation between those systems; a single product still needs a demonstration that each step works.

A buyer acceptance checklist

The following checks are proposed evaluation scenarios, not results of tests performed by StatWharf. Run them in an authorized non-production landscape with representative configuration. Define expected evidence before the demonstration so that a polished request form does not substitute for proof of the complete control.

1. Attribute activity to the responsible person

Start with a named requester, a ticket reference, an approved purpose and a bounded target system. Ask for the record that connects the person to the elevated identity or temporary privileges. Where a separate firefighter account is used, include overlapping requests and attempted reuse. Where privileges attach to a personal account, establish how the elevated interval is distinguished from ordinary activity.

The desired output is a traceable chain from request through grant to recorded work and review. Decide whether the evidence must distinguish human users, service identities and automated jobs. A shared account name alone may be insufficient for the organization’s attribution requirement. Record how identity changes or departures affect historical evidence, rather than assuming that today’s directory entry preserves yesterday’s attribution.

2. Test approval boundaries and exception handling

Use a routine request, a high-risk request and a request outside normal support hours. Specify who can approve each, whether the requester can approve their own access, and how a substitute approver is selected. Ask what happens when the request changes after approval: a new target, longer duration or broader privilege set should have an explicit treatment.

An urgent exception policy should name the authority that permits access and the person who reviews it afterward. The acceptance record should show which route was followed, its timestamps and any reason entered. An approval button demonstrates an interface; the test must also establish what authorization was actually granted in the target system.

3. Prove that access ends

Request a short interval and observe the target authorization after expiry. Repeat with an active session, a failed connection and an interrupted background job where those scenarios are relevant to the proposed architecture. Ask whether expiration blocks a new login, removes an assignment, terminates an existing session or combines those behaviors. Those are different outcomes.

Set a maximum acceptable delay and identify who receives an alert if revocation fails. Preserve both the scheduled expiry and the observed target state. An automatic-expiry claim does not establish that every system and session type behaves identically. The evaluation should expose exceptions before they become production operating procedures.

4. Reconstruct a representative session

Use an approved set of harmless test actions that represents the intended support workflow. Include a transaction and, where in scope, a change to a sensitive field or configuration object. Compare the recorded activity against the known actions. Identify which events are collected, which details are retained and which actions cannot be reconstructed from the selected log sources.

Then request an export that links the activity to the original approval and reviewer decision. Distinguish transaction-level activity, field-level changes and a session recording; they should not be treated as interchangeable evidence. The organization should choose the evidence necessary for its control objective and verify that the chosen deployment actually produces it.

5. Simulate a control-system interruption

Write down the policy for loss of the governance service or connector before testing: deny access, allow a documented emergency route, or use another approved procedure. The correct policy depends on operational needs and the controls surrounding the exception. A vendor’s availability statement is not a complete description of failure behavior.

In the permitted test environment, observe what can still be requested or used during the interruption. After recovery, reconcile requests, grants, target activity and review tasks. Establish how missing records are detected and escalated. Availability of privileged access during an outage and completeness of the eventual audit record are separate acceptance conditions.

6. Complete the review, not just the session

Assign the review to a person independent of the requester under the organization’s policy. Include a reviewer absence, a rejected explanation and an overdue task. Ask the demonstrator to show reminders, reassignment, escalation and closure evidence where supported. A completed support ticket should not silently stand in for a completed access review unless that relationship is explicitly designed and verified.

Record what a reviewer sees, what supporting evidence can be opened, and how a decision is preserved after corrections. If suggestions or AI summaries are offered, distinguish released functionality from prototypes and inspect the original evidence behind a summary. Human accountability and exception treatment should remain explicit even when a product automates part of the workflow.

S/4HANA migration questions to resolve before selection

Build an inventory of systems, releases, identity sources and connection methods that the proposed control must cover. Include the overlapping ECC and S/4HANA period if both remain active during migration. Do not assume that support for one SAP environment establishes support for every cloud deployment, Fiori scenario or connected application.

Map the emergency privileges that must survive migration to their new role and application context. A copied role name is not sufficient evidence that the permissions and restrictions stayed equivalent. Choose representative support tasks and validate the before-and-after permissions in the appropriate test systems. Coordinate this with the SAP role-management decision rather than using an emergency account to compensate indefinitely for incomplete role design.

Plan the cutover of open requests, existing firefighter assignments and pending reviews. Decide whether historical evidence remains in the prior system, moves to a new repository, or is retained through another approved process. Record retention, access and export responsibilities. A replacement proposal should include the cost of preserving usable history, not only the cost of starting new sessions.

Where business applications beyond SAP are in scope, distinguish centralized requests from cross-application risk analysis. A connector list does not establish that the same person’s permissions are correlated across systems or that a specific conflict rule is evaluated. That belongs in the access-risk comparison and requires its own documented test.

Compare the complete operating cost

This guide does not establish product purchase prices. Obtain a written scope covering the required module, deployment, target systems and identity populations. Ask which environments count toward licensing, how temporary or shared accounts are treated, and whether implementation, connectors, upgrades and support are separate line items. Do not compare an entire governance suite’s quote with a standalone emergency-access module without normalizing scope.

Include recurring work in the cost model: maintaining privileged roles, repairing identity mappings, reviewing sessions, handling failed revocation and producing evidence. Use the organization’s own request volumes and measured evaluation effort. A vendor’s promised time saving should remain a claim until a representative workflow demonstrates it.

Create an exit requirement alongside the purchase requirement. Specify the evidence formats, historical identifiers and configuration documentation needed if the tool is replaced. Confirm who can retrieve those records and for how long under the actual agreement. Portability is an evaluation question here, not a capability attributed to every listed vendor.

Record the decision

This guide addresses temporary privileged SAP work, not every privileged-access or identity-governance requirement. A generic password vault is not automatically equivalent to transaction-aware SAP access governance. Conversely, a SAP-specific control should not be assumed to meet infrastructure-privilege requirements.

Periodic recertification asks whether continuing access should remain assigned; emergency-access review asks whether a particular exceptional use was authorized and appropriate. The two processes may share owners or tooling but need distinct records. Consult the SAP user-access-review comparison for recurring certification needs.

For each proposal, record the product and edition, supported target releases, requested evidence, observed result, unresolved condition, accountable owner and price for the same scope. Label each capability as documented, demonstrated during evaluation, contractually included or unresolved. Those labels prevent a public marketing description from becoming an unsupported assertion about a future deployment.

Download the evaluation worksheet. It contains the six acceptance checks from this guide and blank fields for actual evaluation results. Blank fields are intentional: no product has been evaluated with this worksheet by StatWharf.

Sources and commercial policy

The native baseline and lifecycle discussion use the two linked SAP publications, reviewed September 10, 2026. The acceptance scenarios and cost questions are editorial analysis, not SAP requirements or a compliance certification. Confirm current deployment support before relying on version-specific documentation.

No sponsor commissioned this guide. StatWharf offers separately labelled paid product profiles. A paid profile is a commercial placement, not an independent endorsement or an exhaustive vendor shortlist. Sponsorship does not change this guide’s factual conclusions or the documented comparison criteria.

Factual corrections are free: editorial@statwharf.com.