Skip to Content

Configure Emergency Access (EAM) in GRC 10


Configuring EAM in GRC 10 isn’t a difficult task, but there are some details you have to take into account. The document “AC 10.0 Pre-Implementation From Post-Installation to First Emergency Access” is useful, but it doesn’t  consider all the details. Here I’ll try to give you a complete explanation about how to configure EAM successfully.

Configure Parameters:

In GRC Box, execute transaction SPRO and navigate to here:


The following parameters should be set according to the table:


Recommended value (for initial configuration)

4000‐Application type


4001‐Default Firefighter Validity Period (Days)


4002‐Send Email Immediately


4003‐Retrieve Change Log


4004‐Retrieve System log


4005‐Retrieve Audit log


4006‐Retrieve OS Command log


4007‐Send Log Report Execution Notification Immediately


4008‐Send FirefightId Login Notification


4009‐Log Report Execution Notification


4010‐Firefighter ID role name

Chose a role name, for example


For a complete description of the above parameters, please refer to the guide: – > SAP BusinessObjects Governance, Risk and Compliance (GRC) -> Acess Control -> Release 10.0 -> Maintaining Configuration Settings Guide – SAP AC 10.0

You might want to change some of them; the recommended values only serve as a guide for the initial configuration.

Changes in the parameters table will be included in a transport request, you should release the transport to your QA/PROD systems when you finish the EAM tests and adapt the parameters according to your requirements.

Parameter 4010: What’s for?

If you’ve been working with GRC 5.3, this parameter should sound weird to you.

The purpose is to identify to the application that the user who is logging on to the target system is a Firefighter ID. The target system makes a call to the GRC Box and reads this configuration to check if the user has this role assigned to them.

That means that you have to create the role that you’ve set in parameter 4010 in all the target systems with the exact name provided there. Usually, you copy it from the standard SAP_GRC_SPM_FFID (it contains RFC authorizations).

Only the users who have that role assigned in the target system will be available for selection in the GRC Box as Firefighters IDs.

Kindly check note: 1668255 – Firefighter ID role name for Param ID 4010

For more information regarding default roles provided by SAP, please refer to Security Guide available here: – > SAP BusinessObjects Governance, Risk and Compliance (GRC) -> Acess Control -> Release 10.0 -> Security Guide – SAP Access Control 10.0

Adding connector to the SUPMG Scenario:

Please check: Note 1562760 – AC10.0 – Intergration Scenarios to Connector link

At this point you have already created the connectors.

Now you have to link the corresponding connectors to the SUPMG scenario:



Click here:




Required roles in the GRC Box:


SAP provides standard roles that must be copied to the customer namespace. For this sample configuration you should need at least to create a copy for the following roles and generate the corresponding profiles:


Emergency Access management owner


Emergency Access management controller


Emergency Access management firefighter


Emergency Access management administrator


Gives basic authorizations required for all AC users. You must assign this role to all AC users.


Gives the authorizations to launch NWBC. You must assign this role to all AC users.

You can just name them as Z_<full standard role name> or use a naming convention according to your company requirements.

CAUTION: Please, follow he instructions provided in tha attachment of note:

Note 1663949 – EAM Authorization Fixes for Central Owners and Reason Codes

There are some changes you have to made to the standard roles and also there’s a complete explanation of the authorization objects.

For more information, kindly refer to the Security Guide (link provided above).

Security considerations for EAM Roles:

Kindly read a specific authorization guide for EAM that is attached to the note:
Note 1663949 – EAM: Authorization Fixes for Central Owners and Reason Codes

and take into account the authorization concept for the roles:

1730649 – Firefighter owner can assign ANY Firefighter ID to Firefighter User


“As per the functionality in AC10, we have concept of role based authorization. If a user is having SAP_GRAC_SUPER_USER_MGMT_OWNER  role at the backend, then he  should be able to assign any FFID to any Firefighter user.

The user Assigned with the Role of EAM Admin “SAP_GRAC_SUPER_USER_MGMT_ADMIN”
and EAM Owner “SAP_GRAC_SUPER_USER_MGMT_OWNER ” can do all available owner action for all connector.
The Auth. Object used for firefighter Maintenance is GRAC_FFOWN & GRAC_OWNER”

—->>> vote for a simpler way if you disagree with this weird role-based model !! –>>> Simple setting for EAM owner/controller authorization

If you are not going to use ARM workflows and you want to restrict Owners, please have a look at the thread:

GRC EAM Authorizations: Few Anomalies in Standard Roles

(Provided by Akshay Gupta)

Required users in the GRC Box:

In order to show a sample for testing, It’s necessary to create (or use existing ones) three users:

FF_OWNER: This user will serve as owner for the firefighter ID. It should be assigned to the role Z_SAP_GRAC_SUPER_USER_MGMT_OWNER

FF_CONTROL: This is the firefighter controller. You assign Z_SAP_GRAC_SUPER_USER_MGMT_CNTLR.

CAUTION: This user MUST have a valid e-mail address maintained in SU01 if you want the controller to receive notifications via e-mail.

FIREFIGHTER: This is the firefighter user, who will be able to access in the target system with the Firefighter ID. You assign Z_SAP_GRAC_SUPER_USER_MGMT_USER in addition to the base roles. If you don’t assign the base roles you won’t see the user (FIREFIGHTER in this case) available for selection in the Firefighters IDs.

<your user>: The user who is going to perform the configurations, must have at least the role Z_SAP_GRAC_SUPER_USER_MGMT_ADMIN assigned.

In addition to all the mentioned roles above, all users must have the roles Z_SAP_GRAC_NWBC and Z_SAP_GRAC_BASE assigned.

For a theoretical explanation of the users and its responsibilities, refer to

Required roles in the target system:

In the target system you have to make a copy of the role SAP_GRAC_SPM_FFID and generate the profile.

CAUTION: The name of this role MUST be the same configured in the parameter 4010 in the GRC Box. In this example: Z_SAP_GRC_SPM_FFID.

Required users in the target system:

You have to create a user (FIREFIGHTER_ID) in the target system with the corresponding roles required roles/profiles according to your requirements. In addition you must assign to the FIREFIGHTER_ID the role Z_SAP_GRC_SPM_FFID.

This user should be of type: “Service” as per note 1702439

The following note describes an issue you’ll face with this kind of users: Note 1586989 – Object Services icon not available in Firefighter ID session

I’ll update this document when a specific note for GRC 10 is released regarding this issue.

Take into account this important note for service users: 1945098 – Service users are not considered in decentralized firefighter

Creating central Owners and controllers:

Access to the NWBC:  http://<server>:<port>/nwbc/ or execute Tcode NWBC in the GRC Box.

Go to the “Setup” tab and:


Create entries for the Firefighter controller and owner:


Creating reason codes:

You have to create at least one reason code to be able to use the firefighter ID later.



Associate the entry to the corresponding target system.

Synchronization Jobs:

In accordance with note: 1585079

You have to execute the synchronization Jobs in order to make the FF IDs available in GRC Box for selection:

Please make sure that you have performed following configuration steps:

1. Integration Scenarios are configured as explained in note 1562760

2. Please make sure the Firefighter role is assigned to Firefighter IDs in the corresponding client system and that the same role has been given as parameter value for configuration parameter 4010. Configuration parameters can be configured in the transaction code SPRO => Governance, Risk & Compliance => Access Control => Maintain Configuration Settings

3. Run User/Role/Profile/Auth synchronization jobs. The Link to run these jobs can be found Under transaction code SPRO => Governance, Risk & Compliance => Access Control => Synchronization Jobs.


Once you have executed the Repository Sync job with the corresponding target connector, the FF ID will be available for selection in the GRC Box.

See also Note 1668255

…Once you are done with the above steps, re-run an Incremental/Full User Sync for the Firefighter IDs with the Firefighter Role to be SYNCed into the GRC box.Now re-launch the application via NWBC or Portal and then search for the Firefighter ID and this should be available in Firefighter ID list.


Assign Owners:



Assign Firefighter IDs to Firefighters


Here you assign the Firefighter ID to the corresponding Firefighters users (one or more)


And in the controller tab set the controller user:



Mass upload of assignments: In case you need to perform an initial load or a mass maintenance you can use one of the programs provided for migration as described here 1744929 – Mass Upload of Assignments for EAM

Also check the following note if you require a mass reassignment, for example, mass change of an owner that is currently assigned to many FF IDs:

2072846 – FF mass maintenance


Firefighter collector Job:

Execute tx. GRAC_SPM_LOG_SYNC and schedule the log collection periodically as per note: 1617529

Known problems with time zones:

Note 1595462 – Logs not visible in the SPM Reports

Note 1775432 – Transaction logs are not getting captured by GRC 10.0

Known problem when connector is set to “*”:

Note 1726157 – GRAC10 EAM GRAC_SPM_LOG_SYNC_UPDATE doesn t collect data

Performance problems :

Note 1750024 – GRAC – Performance of the SPM Log Sync

You’ll find many notes in SAP Marketplace related to performance issues.

Other errors:

Note 1773855 – EAM10.0 Sometimes Workflows and transaction logs are missed

Note 1776070 – GRC EAM program is giving a short dump and no logs generated

Note 1731923 – EAM:Transaction Logs are not being captured while sync


Have you lost EAM logs?


If you lost some EAM logs and the data is still available in the plug-in system you can schedule a time-based special sync:

1934127 – GRC10 EAM: EAM recovery program to retrieve missing log and to generate the missing workflows

E-mail configuration (Centralized Firefighter):

If you want the controller to receive e-mails (firefighter log on notification and firefighter session details) you have to check the following:

  • Make sure your Basis team has properly configured outgoing e-emails from GRC Box (Tx. SCOT)
  • Controller notification method was set to: Email (see above)
  • SPRO parameters:

4002 Send E-mail Immediately YES

4007 Send Log Report Execution

Notification Immediately YES

4008 Send FirefightID Logon Notification YES

4009 Log Report Execution Notification YES

  • Controller user (FF_CONTROL) has “Comm.Method” set to “E-Mail” in SU01 and has a valid e-mail address.
  • WF-BATCH User must also have an e-mail address in SU01; otherwise you’ll get the following error in tx. SLG1:


According to the configuration settings guide:


You can change the parameter and use another user to send the e-mails.

After executing the GRAC_SPM_LOG_SYNC_UPDATE, please execute tx. SOST and check if the e-mails were generated (you have to access the firefighter to get the e-mails).

Implement Firefighter user Exit:


Despite the Firefighter ID password is changed by the application each time you start the firefighter (you can check it via change documents in the target system), Firefighter Ids need to be restricted from Logging in into SAP System directly via SAP GUI. For this purpose either we need to create and modify the SAP User Login Exit.


1545511 – Firefighter User Exit

1735971 – User exit to prevent direct firefighter login

Security Issue???:


If the user exit is properly implemented you’ll get the following message when trying to log-on directly with a Firefighter ID (or any user assigned to role configured in the parameter 1090 in the plug-in System !!!):



Required RFC connections for EAM:

Please check: Note 1701047 – Is it mandatory to use trusted connection in the RFC destination for Firefighter Connector?

“Yes it is mandatory to make a trusted relationship so that communication can be established between the GRC system and the plug-in.”


This topic has been discussed here (see comments below). The note is for Centralized FF and true is that it works anyway with non trusted connection. In case of decentralized model the connector is used to retrieve logs, so it doesn’t need to be trusted.


Links to more documentation:

Note 1394281 – Superuser Privilege Management Log Report Content

Note 1065048 – Firefighter Log Not sent in Email to Controller <<- for 5.3, but useful

Note 1618040 – Performance fix for SPM transaction logs for large systems

Note 1732938 – Firefighter incorrect language setting on ERP Production

Note 1730649 – Firefighter owner can assign ANY Firefighter ID to Firefighter User

Note 1747283 – EAM: Entries in EAM logon pad not Visible for a firefighter

Decentralized firefighting (as in GRC 5.3) is available as of GRC 10.0 SP10

As of SP10, Emergency Access decentralized firefighting features are available.Users can install and use the EAM Launchpad to perform ID-based firefighting directly on plug-in systems. This means that Firefighter session could be started from the plugin system itself without the need to access the GRC Box. This approach was used in GRC 5.3. With GRC 10 SP10 you can chose between centralized or decentralized firefighting.

The most important advantage of decentralized firefighting is that you can continue using firefighter even when the GRC Box is down. In my opinion, it’s also more “user-friendly” since the firefighter doesn’t have to log on to GRC Box in order to start the firefighting session, he/she only needs to execute a transaction in the plugin system. For some companies, the centralized approach is better since the user access to a system (GRC Box) and can start firefighter sessions in multiple systems.

Bottom line, the most important thing is that with SP10 you have to option to choose and below you’ll find information that’ll help you to configure decentralized Firefighting.

The idea of a decentralized firefighting wassubmitted by Daniela Bork on SAP Idea Place: Access Firefighter application locally in AC10

So, if you have a good Idea, please share it with SAP customers and employees in the Idea Place and maybe it becomes a new functionality!

Main documentation can be found in the guide attached to the note: Note 1690964 – Emergency Access Management Overview Documentation

In the GRC Box a new parameter is available and must be set accordingly:

Under transaction SPRO, navigate to here:


And create a new entry for parameter 4015 which has to be set to the value “YES”


Additionally a new synchronization job is available and must be executed in order to synchronize the EAM data from GRC Box to the plug-in system. Remember that configurations (firefighter assignments, controllers, owners, reason codes, etc.) are still maintained in a centralized way, i.e in the GRC Box.

In order to sync this data with the plug-in, a new job is available and can be found here:



In the connector field you have to set the corresponding plug-in connector.  In order to keep you plugin system updated with the changes you made in the GRC Box, this report should be scheduled periodically, I think hourly would be fine. In addition, if you have multiple plug-in systems, you should follow the same approach as with the log synch: create individual jobs for each connector instead of a unique job with connector value “*”.

Configuration in the plug-in system

In the plug-in system you’ll find new activities under SPRO:


These activities are described in here: 1804207 – GRC EAM 10.0: Configuration parameters introduced in SP10 for EAM

If you haven’t  set the parameter 1000 in the plug-in system, you’ll have to do it in order to use decentralized firefighting, otherwise you’ll get an error message as described here:1800772 – Error ‘No Destination specified’ when using transaction /GRCPI/GRIA_EAM

Then, check the parameter as described below:


If the parameter 1000 isn’t present you have to create it and set the value to an RFC destination pointing to the system itself:


Since this configuration is transported I used to recommend to create a new RFC destination in DEV, QAS and PRD system with the same name, let’s say “GRC_CONNECTOR” and transport the configuration throughout your entire landscape. But nowadays, this parameter is used in the log-in notification e-mail to the controller, and if you are going to use that functionality you might want to create a system name independent connector, i.e. “P01CLNT800” and temporally change the client settings in SCC4 in order to allow the table modification in production systems.

The RFC connection does not require a user. It just has to point to the correct system/instance and a specific client.

Required users

Controllers have to be created in the GRC Box as well as with centralized firefighting. In addition these users must exist in the plugin system and have a valid e-mail address because login notifications are sent from plug-in system

With the decentralized scheme it’s not necessary to create the firefighter users in the GRC Box, because they’ll start firefighter transaction from the plug-in system.

E-mail considerations (Decentralized model)

Log-in notifications are sent from the plug-in system (the e-mail is sent with the Firefighter user, so remember to properly configure it in SU01):


But, as with the Centralized approach, Log  notifications are sent from GRC Box


These requires a proper mail configuration (tx. SCOT) in both systems: plug-in and GRC Box.

General Note for problems with e-mail in decentralized EAM:

1877706 – Login and Log Report Notifications are not being sent to the firefighter controller in case of decentralized firefighting

Plug-in roles

You’ll have to create a new role as a copy of SAP_GRAC_SUPER_USER_MGMT_USER.

You should add the following authorization to it:


For some NW releases ACTVT=02 will be also required. Kindly Check 1753459 – EAM: S_USER_GRP with ACTVT=02 required

This role is assigned to the firefighter users. Bear in mind that these users should not have access to user maintenance transactions, for example SU01. If the firefighter IDs are properly assigned to a group and you can restrict the CLASS field this is not a big issue, since despite they could change the password, they won’t be able to access because the user exit is implemented in order to prevent it.

This extra authorization was documented by SAP in November 2013 in the note:

1944417 – In decentralized firefighting firefighter is not able to perform firefighter logon

Previous versions of this post contain this solution as unofficial, but now has become official.

“..The firefighter is not having the authorization to change the passowrd. In centralized firefighting the password is changed by RFC user, but in decentralized version as there is not RFC connection, the password is changed by firefighter. The functionality works as in EAM 5.3….”

In addition to this role you also have to create roles for administrator and owner. Remember that extending the validity period is a new activity available in the plug-in system and owners and administrators should have access to it.

Known Problems ( specific to decentralized EAM)

Note 1849289 – For Decentral EAM No Reasoncode and Activity desc captured

Specific for CUA systems:Note 1814400 – Decentral call is opening different session in CUA

(Documentation provided by:Guido Stusinsky)

Common Issue: Logon screen appears when starting FF session

It’s possible that we get a log on screen after starting the FF session. This is an incorrect behavior since the user doesn’t need to enter the FF ID password.

Here some tips:

  • Check the RFC connection. Perform an authorization check in SM59 to check if the RFC user is OK.
  • Check that the RFC is pointing to the correct client.
  • Look for dumps in ST22 in the plugin system.
  • Check if the FF ID password is productive, reset the password or check with changing the user to type “Service” if you are using “Dialog” user for FF ID.
  • CUA Systems: Since EAM requires to change the password of the Firefighter ID each time you log-on from the launchpad, the CUA’s initial password needs to be set as ‘Everywhere’ or ‘Proposal’. Please check point 6 of note 1861981 – Things to check when error message ‘Error in opening RFC destination’ appears in GRAC_SPM
  • Have a look at the following notes:

1861981 – Things to check when error message ‘Error in opening RFC destination’ appears in GRAC_SPM

1777094 – EAM log on is not possible with the error: ‘Error found in RFC (plug in system) and respective logon\logons are disabled’

Note 1886332 – GRC 10.0 EAM prompts for user/password while logging

Note 1872709 – Logon popup shown when launching the EAM session

  Common Issue II: Logs are not getting captured

If you cannot get the FF Logs don’t get frustrated. This is not unusual. I’ll give some tips (and hopefully you can help in order to add more!):


  • General recommendations an errors are included in note: 2029368 – EAM Synchronization Jobs Not Completing Resulted in Data Loss
  • It could be to an authorization issue with the RFC      user. The usual one is related to object S_TOOLS_EX as described 1916172 – User Action Usage Sync Error – User ID showing as — ? — . Anyway you can trace the RFC user via ST01 in the back-end while performing a log synch and check if you have some authorization issue.
  • Clock skew: check the system time in the GRC box and compare with the plugin system. You can do it  by check System -> Status at “the same time” in both systems. A clock skew of 1-2 minutes can cause severe problems in the log collection. Time zones do not need to be same… it doesn’t make sense by the way, cause having the GRC box in a Server in India and the ECC in Argentina will be impossible. Even here in South America we usually work with Servers in Chile, Brazil, Argentina and these countries sometimes do not use the same time zone. So…using different time zones has to be a possibility, but you have to be very careful with the clock skews, and if you have differences ask your Server Admins to check it and use a NTP Sever to keep all systems synched.
  • Check that you have data in transaction STAD and ST03N  in the plugin system for the FF ID you’re trying to get the logs. If necessary check with your Basis team if the Statics are being collected  properly.Try executing an action usage synch and check in table GRACACTUSAGE if you have data for the FF ID.
  • Remember to schedule the job hourly as per SAP  recommendation an not running it just when you want to get the logs. This probably will cause lose of data.
  • Check transaction SLG1 in the GRC Box in order to know   the result of the collection. Sometimes you get there the exact cause, for example “RFC Timeout”, “RFC error”, etc.
  • Check for dumps in the plugin system (transaction ST22) and look for dumps created by the RFC user. TIME_OUT or memory related dumps are usual for large systems.
  • SAP has released many enhancements and corrections related to log collection. Just to name one of them that isn’t included in
    the latest SP: 1962440 – GRC EAM – Change Log Collection Performance Enhancement but you’ll find others in the marketplace an probably SAP will release more. Make sure you have all the corrections applied.
  • A last resort when you have problems with log collection (due to performance) would be to create an index on CDHDR table if the dumps in the back-end are related to some queries with such tables and indicate that. The official note is 1741151 – GRC 10.0 Indexing on CDHDR table in case of  time out issue due to huge data Creating an index on such table is something that you have to discuss with your DBA, Basis and Development teams. You have to be very careful with that and you should ask SAP if this is recommended to your scenario and there’re no chances to improve the queries in the code. The table stores change documents and also can be reduced via archiving and this should be also an option to discuss before creating an index.
  • SAP released a note recently indicating that mass activities cannot be performed by Firefighters: 1378276 – Mass Transaction support through Firefighter product

Common Issue III: Firefighter sessions remain open


SAP considers that such issue isn’t specific to EAM: 1290018 – Firefighter ID is locked in Superuser Privilege Management

If the session isn’t open (check SM04 in the plugin system) but the FF is still locked in the launchpad it might be due to a known bug, for example:

2035815 – Firefighter ID (FFID) is shown locked in EAM launchpad, even though no firefighter user is using the same FFID



Co-existence of firefighting models


Both models could be used. The decentralized firefighter configuration doesn’t block the centralized firefighter approach. Since you can start only one firefighter session at a time, you cannot use both at the same time and this is automatically controlled by the application.

Administration functions

The administration functions are maintained in the GRC Box. The decentralized firefighting adds a couple of tasks in the plugin system such as logging notification customizations and the possibility to extend the validity date of firefighters if the GRC Box is down. You’ll find a nice illustration in the guide attached to note mentioned earlier (1690964).

Access to decentralized FF


Some standard roles do not include the correct SPM transaction. In order to start decentralized FF the Firefighter user have to type /n/GRCPI/GRIA_EAM in the transaction bar. If you use other tcodes might see an empty table, and if you don’t use /n you’ll receive a message stating something like it’s impossible to execute this function.

GRC 10.1 – What’s new for EAM??

In GRC 10.1 a new option is included in order to set the Firefighter ID Role (parameter 4010) in a system-independent manner.

SPRO documentation:

“This allows you the flexibility of specifying different firefighter ID roles per plug-in system.
For example, you can specify the following:
For Target Connector ERP_001, the firefighter ID role is Z_SAP_FF01.
For Target Connector ERP_002, the firefighter ID role is Z_SAP_FF02.
If you choose to not use this option, the application uses the role name specified in the configuration parameter Firefighter ID Role Name 4010 for all systems including plug-in systems”

Please share your thoughts, comments or documentation in order to improve this guide.

Well folks, that’s all. Hope this document has helped you to successfully configure GRC EAM 😉




You must be Logged on to comment or reply to a post.
  • The configuration steps are very well explained Diego....excellent job!

    One query - I am not able to get Firefighter Login notifications or Log report as a controller. Although I can view logs in NWBC. What could be the reason?

    I have scheduled job - GRAC_SPM_LOG_SYNC_UPDATE in GRC box and owners and controllers exist only in GRC.



    • Hi Sabita!

      Thanks for your input.

      Regarding your issue, you mean that you're not getting the e-mails as a controller?

      The e-mails are send by default with the user WF-BATCH and look like the following:

      Dear <controller_name>,

      The login notification details for the Firefighter ID <FF_ID> in system <SID> using Reason code '<reason code>' is as follows :

      Firefighter: <firefighter name>
      Owner: <owner name>
      Date & Time: <DD.MM.YYYY> <HH:MM:SS>
      Reason code: <reason code>
      Activity: <activity>

      Kind Regards,
      Access Control Administrator

      Have you checked if the mails are generated in transaction SOST?

      I haven't described the post-installation steps that have to be performed before configure EAM. This is described in AC 10.0 Post-Installation. You have to perform that before configuring the specific modules, for example EAM.
      In particular, the "Activate Common Workflow" (tx. SWU3) described in page 26 is very important, because among other things, user WF-BACTH is created.

      Just for your information, the steps described in my document were tested in SP09.

      If you need more information, please let me know.



      • Hi Diego,

        All configurations are in place. We are at Patch10. There is no job created in SOST for notiifcation.

        Just want to know if there is only one background job to collect firefighter logs, sync it in GRC and send the mails or there are more than one job? SCOT configuration is in place and mails are being sent from SAP office.



        • Hi Diego,

          There was small problem, WF-BATCH was not having a mail ID in user record. Now login notification is being sent, but log summary report is still not sent.

          Is there any other job for that?



          • Hi Sabita,

            There's only one job. Have you checked parameters 4000 to 4010 as described in the document? is the log available in the NWBC?. I faced some problems because of the time in the plugin system was different than the time in the GRC BOX (for example 15 min. difference).



          • Hi Sabita,

            I'm currently working in a new system and I'm facing some issues with SPM log SYNC performance. While searching for some notes I've found this:

            SAP Note 1773855 - EAM10.0 Sometimes Workflows and transaction logs are missed

            Have you checked? Have you solved the issue already?



          • Hi Diego,

            I am getting login notification, but not the log summary report. Additionally, I have scheduled GRAC_SPM_LOG_UPDATE job and activated FIREFIGHTER_LOG_REPORT workflow, but no luck. If above SAP note solves the problem, let us know.



  • Hi Diego, excellent job, very usefull !

    I have a question regarding the configuration : is there any specific configuration to be done to be able to assign FFID to firefighters throught a request rather than assigning them directly throught NWBC / Setup / Superuser maintenance / Firefighters ?

    When I assign them manually I see the list of available FFIDs, but when I try to assign them throught a request I see only few of them and even more the list is empty if I perform a search in the selection screen.

    Any idea ?



    • Hi Emmanuel,

      Thanks for your input. I haven't tried configuring assignment via workflow so far. You might want to check the configuration steps described here: or otherwise please create a new thread describing the configuration you've performed and the issue you're facing and I'm sure someone will be able to help you.



    • Hi Emmanuel

      Thanks for the detailed configuration document for EAM. I have followed all your steps but still when I am trying to assign FF user to FF id I don't find the entry in nwbc when I search it.Also I created test ids for Owner & Controller with FF user in GRC box but I was able to assign owner and controller but FF user not able to find.

      Please help me on this.



      • Hi Pradeep,

        Remember that It's mandatory to execute role/profile/user sync against the back-end system for FF and the FF ids must have the corresponding role assigned according to parameter 4010.



        • Hi Diego,

          I have done all the steps mentioned by you but still FF user does not appear in the search.

          Also I can't see my Test Owner and controller created in the GRC box in the search option but when I was assigning owners and controllers I am able to find them.

          Also we have CUA in our landscape so I have made CUA connector as my master user source.

          also I used SAP_GRAC_SPM_FFID role for parameter 4010 in GRC box and 1090 in ECC box.

          Please help me to resolve this error.



          • Hi Pradeep,

            I haven't configured EAM with CUA but I'd try to configure first without CUA in order to know if the problem is related to that.



          • Hi Diego

            I have solved the issue.But I have another question this background job for SPM Log sync should be scheduled in GRC box with the connector variant?.I have executed the program and created a variant with ECC system is it ok?



          • Hi Pradeep.

            I'm glad to know that your problem has been solved. If you feel the solution you applied to fix could help others, please share it 😉

            Regarding the log sync job, you have to create a variant with the corresponding connector (is not recommended to use * as connector) and schedule the the report with the variant hourly. details can be found here:


            P.D: I hope to test decentralized FF (available with SP 10) soon, and I'll try to add the relevant information to this document.



  • Diego,

    This is an excellent article. I like the way you provide links to Std SAP documentation, various notes and also highlight the decentralized EAM approach. This document would serve as a central repository for any EAM configuration 🙂

  • Hi Diego,

    Just implemented EAM and, like the others, I found your article extremely helpful.  Thanks for saving me a lot of trial and error!

    One question I had after successfully receiving the login notifications and activity logs for my test user - I thought I heard that the controller would be able to review and approve an activity log IN the GRC system.  Thus, retaining the log AND their approval together in GRC for future audit reviews.  We're currently using SPM from the 5.3 version and our approvers are retaining hard copies of the logs, obviously an inefficient and wasteful practice.  Is this approval retention option available, as I thought, and do I need to complete a workflow implementation to take advantage of it?

    Thx again for all your help!


    • Hi David,

      Yes it's possible to configure a workflow and I think it's the best option in your scenario. In GRC 10 the WF is called "Fire Fighter Log Report Review Workflow" and there is a standard configuration that can be useful for simple approval scenarios.



  • Hi Diego,

    thx a lot for this document, FF from GRC box works fine.

    Next step is now  decentralized FF.  I' ve got an error when logon with my FF ID:

    "You can only distribute the data from the source system"

    Parameter 1000 in ECC box is set to ECC RFC destination itself.

    any idea?



    EDIT: my error is fixed.

    If you are using decentralized FF in a CUA enviroment--> implement SAP note 1814400

  • Hi Diego,

    Excellent document and I've used it to configure my test setup and but have across a problem as outlined here so you're input would be valuable. I'm just double checking this doc again to see what I may have missed.

    Again a very good document.



  • Hi Diego

                 Thanks for explaining thing in such detail, A small point can we configure

    actual user id for owner and controller if yes , then what is the purpose of defining the values

    Owner Type                 FFCR, FFCU, FFID, FFRO

    in the roles


    it means what is the purpose for the following values FFID , FFCU and others  ?

    Also I am not able to assign my actual user id to fire fighter owner , It says "you cannot assign yourself as owner" no idea why this is happening any answers please

    thanks for reply


    • Hello Akhil,

      You can configure the same user as owner and controller; the system doesn't restrict that but you have to understand if this makes sense theoretically in your scenario since the responsibilities are not the same (see mentioned documentation).

      The firefighter role owner and firefighter role controller aren't used in the document because I've only explained the ID Based scenario. There's also a Role-Based scenario where the user gets a FF Role instead of a user. This scenario is not usually implemented and I don't know if someone found it useful.... 😕 .

      Regarding assigning yourself a firefighter, there's a GRC restriction, since it doesn't make sense to assign yourself as a firefighter. If you want that for testing purposes you've to create a FF owner, log in with the user and assign the FF to your user.



  • Hello Diego

                    Many thanks for your reply,

    I do understand the point you mentioned for role based and Id based

    I am implementing GRC at one of the client

    I list the steps  point wise to make it more clear -

    1. Under ACCESS MANAGEMENT work center    I can assign FF Owners and Controllers

    2.  So under   “Access Control Owners” I assign my user id as FF OWNER


    4. I am trying to ASSIGN FIRE FIGHTER ID to OWNER (Which is my user id )

    It gives following error message

    "You cannot assign yourself as an owner   "

    5.  I am not clear with the error message does it means .

    6.   I can create my user id as owner but I can not assign my user id to fire fighter id is it correct?

    Thanks for your reply


    • Hi Akhil,

      I think that it makes sense if the system restrict a owner to assign a firefighter to himself/herself. If you want to use a firefighter you should ask another owner to assign you a firefighter.



  • Hi everyone,

    one simple question for my understanding: I find it weird that at the moment, my FF Owner sees all FF IDs in the system, even those, for which he is not the owner. I remember that in GRC 5.3, this was different (and more logical): every FF Owner sees only those FF IDs for which he is the owner...

    I'm sure this can be customized somewhere (spro? auth objects?), but I couldn't find the spot yet. Does anyone have a clue?

    Thanks in advance.

      • Hi Diego,

        thank you very much for the information, the article 1730649 explains it very well. Now, suppose I still want to change this setting, so that each owner only sees "his" FF IDs. Is there a way to achieve this? Thanks in advance.

        Best regards,


        • Hi Darie,

          You can work with the authorization objects GRAC_USER and GRAC_OWN.

          as mentioned in the guide:

          "User ID : This Field Specifies which firefighter users you can Display and Perform other activities based on the Activity Field .

          NOTE: To access Firefighter IDs, User should have at least display authorization for the FFID and Owner combination ie display rights on GRAC_OWN. (Refer authorization point 3)."

          for example, if you give one owner the authorization GRAC_USER with activity 03 for all users, but restrict activities 01,02,06 only to the firefighters he/she owns, this owner will be able to display all firefighters, but when tries to assign a FF that doesn't owns, the following message appears:

          "Authorization missing for Firefighter <firefighter> to FFOBJECT/<EAMUSER>/<CONNECTOR> maintenance"

          Bottom line, you have to work with authorization objects to restrict each owner.

          I don't like this "new concept" that differs from 5.3 approach where the restriction was easier to maintain, specially if you have a large number of owners.

          Bear in mind that you can also work with an ARQ workflow to assign firefighters to users.



  • Hello Diego,

    Thank you for this information it was most helpfull.

    We have configured our GRC10 system and did the connectors to the backend system, Firefighter/ID's/Owners/Roles are setup successfully. we have tested the logons/Notification and sync jobs runs as well.

    Question: When reviewing the consolidated Report to see what changes the FireFighter has made say via se16n to a table, the log only showed that the fire fight accessed the tcode but not showing old or new values?

    PS: we tested changes via SU01 changed user information and synced and the logs reviewed the report and had the value that was changed from X to Y. but this did not happen in Question 1.

    Thanks in advance


  • Hello Diego

                        Small help required , I have configured mail notification for EAM logs

    the mail I am receiving is in following format

    So I have to click on LOG DETAILS to login in GRC server to see the details

    do we have any option to get attach document  in the mail of the FF-log?

    Dear FFID Controller,

    The firefighter 70001260 had logged in using FIREFIGHTER on system PR3CLNT300 .

    Log Report can be found at Log Details

    Kind Regards,

    Superuser Privilege Management

    Thanks and Regards

    Akhil Chaudhry

  • Hi Diego,

    really excellent documentation.

    What about the EAM Workflow configuration? I don't find any documentation to that. But that is what the value is with 10.X.

    If you could send me a useable one I would appreciate that.



    • Hi Murat!

      Unfortunately I don't have such documentation. The idea of this post is to create a collaboration site, so if anyone has some details to configure WF for log review/ FF assignments I'll be glad to add it to the post.



  • Hi Diego,


    My client is planning to implement GRC in the near future. In the meantime, we are planning to implement  the decentralized EAM. For this purpose, we have installed AC10 plug in  “GRCINW V100_731  SP level 0004”.   Current SAP Basis & ABAP patch levels are 7.31 SP level 5.  


    As per the documentation, we have set the parameter IDs 1000, 4000, 4001, 4008 and 4010.  When I execute the EAM launch pad t-code /GRCPI/GRIA_EAM, the first screen shows  with title “ Emergency Access Management”  and  refresh button only. No other options  are available on the screen to  setup owners, firefighters and controllers, etc.  Would appreciate if anybody could share the reason for the above issue.

    I was trying to use  /GRCPI/GRIA_EAM   the same way   /VIRSA/VFAT is being used in the Plug In systems for emergency access.

    Thanks in advance,


    • Hi Reji,

      This is as per design. The possibility of setup owners, firefighters, controllers in the plug-in system is a GRC 5.3 functionality. For GRC 10 you can use the FF in a decentralized way as in 5.3, but the administration has to be done in the GRC system. Please review the guide attached to the note:

      Note 1690964 - Emergency Access Management Overview Documentation

      You can have a look at pages 19 to 22.

      In the section "EAM Activities Maintained on the GRC System" you'll notice that the actions you've described are commented as "Maintained on the GRC system".

      That's why you have to schedule the "EAM Master Data Synch" job if you want to use the decentralized FF.



      • Hi Diego,


        Thank you very much. I was under the idea that  it can be used the same  way  /VIRSA/VFAT being used in the plug in systems.

        However, I  was able to configure /VIRSA/VFAT for the decentralized emergency accecss with the same plug in components provided by SAP.



  • Hi Diego,

    This is one of the most articulated documentation on EAM I happened to found. Specifically the new Decentralized feature, which you have elaborated in depth.

    I happened to have work earlier with the centralized EAM, but recently after raising SPs beyond 10, decentralized firefighting is the real calming effect for the end-users. I was really hoping for this detailed piece of information.

    Excellent documentation, you just nailed it.



  • Hi Diego,

    🙂 Thanks a lot for the elaborated document.

    Did you configured ARA and ARM also, if so could you please upload the same docs.

    Thanks again. 🙂

    Best Regards,

    Ravi Kumar

  • Hi Diego,

    Its an awesome documentation. Just had a quick question, we are planning to implement centralized EAM for our customer. For this purpose, we have installed GRC AC 10 SP13 with AC10 plug in  “GRCINW V100_731  SP level 0004”. Since we are using centralized firefighting, do we need to maintin the parameter 1000, 4000 & 4010 in the backend application? I was referring to the notes(0001800772 & 0001804207) in your blog and it mentions to maintain these parameters for decentralized fireifghting.

    Appreciate your help in this regards.

    Thank you.

    Anjan Pandey

    • Hello Anjan,

      Have you installed the GRCINW V100_731  SP level 0004 on the GRC Box?? this component as well as the GRCPIERP has to be installed only in the back-end.

      If you're going to use centralized FF only it's not required to maintain parameter 1000 in the back-end but you have to maintain parameter 4000 as 1 and the 4010 with the FF role. The latter will be used for the user exit.



      • team.

        Is the FireFighter ID is the Plug-in system ( Backend ECC system ) a service Id?

        I am assigning the FF id to the owner and the id does not populate 1-20-2014 1-43-05 PM.jpg

        image shows that "

        No records found for the search criteria entered.

        All the task are configured as to your specifications , Background jobs have run,

        Any help is appreciated ?

        1-20-2014 1-43-05 PM.jpg
          • Hello

            We are currently on SP11. We have been live with PC  .

            Would there be an Serive Pack impacts with upgrading to SP 14 with this note ?

            Also on looking at the note it specifies to refer to 1878025 . On opening this note , it states"Document not released"

          • In that case you can raise an OSS with SAP if earlier it worked with SP11.

            You are using the standard Role SAP_GRAC_SPM_FFID, I believe the profile of this is already generated.

            The user you are using to display/assign FF IDs, must have sufficient authorizations (Firefighter Administrator role to begin with). If not can you do immediate SU53 after trying to search for the FF IDs.



        • Hi Parag,

          Please assign role(what you mention in 4010‐Firefighter ID role name) to FireFighter ID in Plug-in system ( Backend ECC system ) .

          Thanks & Regards

          Subbu Gogineni.

        • 1) Ensure to have assigned the Role SAP_GRAC_SPM_FFID or its copy which has RFC authorizations. Also maintain this in the corresponding SPRO Configuration Parameter 4010.

          2) FF ID type should be service.

          3) Also synchronize the repository object sync from Back-end to GRC system to  be able to make use of the FF ID in the GRC System.



          • Team,

            Here are the following items that I have verified /validated

            2.I have assigned the roles SAP_GRAC_SPM_FFID SAP_GRAC_SPM_FFID in 4010 as well as FFid plug as the identical role with S_RFC authorizations.

            3. FFid  is service type

            4. OBjects are synchronized in the backend system

            5. The connector value ( G2SCLNT100) in plug in system(ECC)correspond the identical value .

            Still the issue exist

  • Hi Diego,

    Recently I came across an article (link mentioned below) which talks about defining the log review workflow SLA based on Criticality level of firefighter ID. When I went to define the SLA for process ID SAP_GRAC_FIREFIGHT_LOG_REPORT, there was no option to define SLA's based on criticality level.

    Do you have any idea regarding the configuration steps for thsi requirement.

    Note: We have installed GRCINW V100_731  SP level 0004 in our GRC system.

    Any help will be appreciated.

    Let me kno wif you need additional details.

    Thank you.

    Anjan Pandey

  • Hi, I apologize if I missed a reference to this in your documentation, but I have a question.  If the passwords for the EAM IDs are set up as deactivated in both the GRC 10 central instance and the connected target system, why is it necessary to apply the GRC 10 user exit in note 154551?

    Thank you, Jane Landreth


    Link to Note:

    • Hello Jane,

      You usually don't have EAM IDs in GRC, you only create firefighters IDs there if you use centralized approach. You can have EAM IDs in GRC only if you use EAM in the GRC box Itself, in such case you have to install GRCPINW there and this is not recommended (or at least you should check with an OSS message)

      EAM won't work if you use deactivated passwords. The password is changed by the EAM application each time the FF logs on the plugin system, so if you set the password as deactivated it won't work.

      Hope it helps.



      • Hi, Diego.  We did not implement the user exit note, but have found via testing that an EAM user with a deactivated password in the plugin system is unable to directly log in to the plugin system but is able to log into the centralized GRC 10 instance and be connected to the plugin system for firefighting.   We have not had any problems with having a deactivated password in the plugin clients so I'm confused......

        Any thoughts?  I'd appreciate any input.

        Thank you!

        Jane Landreth

        • Hello Jane,

          Definitely is something wrong with that. that shouldn't work that way.

          Anyway, using deactivated passwords isn't supported by SAP. You might open an OSS message and ask for such behaviour, but the correct way is yo implemente the user exit.

          Using deactivated password you shouldn't be able to use the FF.



          • OK Jane!

            Please keep us updated with that. This is a colaborative document and the idea is to add the knowdelge and imput of all of you!! 😉


          • Hi Jane,

            Just for curiosity I've tested in my system SP14 and it doesn't work if you deactivate the password for the FF ID. When login form the GRC Box If you're using centralized FF you should get:


            Every time you login, the RFC user (in case of centralized FF) will change the FF ID Password and this is shown in the change documents:


            Where in the painted text you should have the RFC user as the one dont tha password change.

            So there's no way to get the FF work using deactivated passwords for FF ID. either you have something incorrectly configured or there's a problem in some standard code.

            Hope it helps.


          • Hi, Diego.  I think you found the answer!  I checked our system and we are at SP13 -  which explains why in our centralized GRC 10 instance, that EAM users with deactivated passwords in the plug-in system can log-in via GRC 10 and be connected to the plug-in client.

            If we upgrade to SP 14, then I think we'd have to implement the FF User Exit Note 1545511
            .  Do you agree?

            Thank you!

            Jane Landreth

          • Hi Jane,

            nope...I think you have something that's not properly configured... I don't think this is about the SP level.... are you sure that the FF Id has the password deactivated in the plugin? when you log-in with the FF, do you have the changed documents as i mentioned?



          • Hi, Diego.  First, thank you very much for all of your help!

            I did some checking and here's what I found:

            • EAM ID set up as Dialog ID in central GRC 10 instance - user is showing as not having logged on (although ID was used during testing)
            • Same EAM ID set up as Service ID in target system with valid log-in date and deactivated password.

            Thank you, Jane

          • Hello Jane,

            Maybe if you describe the whole scenario you have configured we can help. But definitelly there's something wrong with that:

            EAM ID set up as Dialog ID in central GRC 10 instance - user is showing as not having logged on (although ID was used during testing)

            You don't have to create FF IDs in GRC box.... I'm not understanding your point....



  • Diego: Its really quite an explanatory document involving all the important steps to configure EAM. Thanks a ton for sharing this valuable document.


  • I am seeking help.  We have connected Dev, QA and Production SAP clients to our centralized GRC 10 instance.   We tested the following:

    1. Firefighting in a Dev plug-in client via GRC 10:  Worked fine - log generated and email sent to the controller.
    2. Firefighting in a QA plug-in client via GRC 10:  Doesn't work - no log is generated and no email sent.

    Any suggestions as to how to resolve our issue?  We've checked the configuration, connectors and compared the access between Dev and QA and can't find what is causing the problem.

    We'd appreciate any input!

    Thank you,

    Jane Landreth

  • Thanks Diego for the documentation - its great

    had some queries though as following:

    1. in grc10 EAM config - are you using trusted rfcs? if yes - that means to run a batch job ..whoever is running that batch job has to exist in both systems - centralized grc box and the target connector ? isnt it unnecssary to have user created in target system just because you are using trusted rfc

    2. if we are using trusted rfc - how will s_Rfcacl object be maintained - its impossible to tie down this object without putting an "*" in rfc_user field - which contradicts SAP's purpose of having this objcet in first place (while we maintain "*" in this field - we also get a warning message along with a note no. to not to put "*") .. I may be missing something but cant seem to think why the two ends shall meet i.e trusted rfcs in centralized firefighting system and s_rfcacl object security for protetcting those trusted rfcs ...

    also what is the advantage or reason of having trusted rfcs in first place ? whats wrong with std. rfc if I may ask so - ofcourse this should be addressed to SAP but just wanted to check if you are aware?

    Best Regards


    • Hello Prashant!

      I get your point and I've configured EAM without using a trusted relationship and it works fine, but as the note stated there is a security issue with that: 1904831 - Concept of Trusted RFC in Firefighter application
      I think  that this is an issue will have with any kind of RFC adn not just related to GRC.

      Regarding the synch jobs and so on...if you're not using trusted RFCs you anyway have to create a user in the plugin system and set the user/password in the RFC connection you have in the GRC box.... so I'm not seeing any specific dissadvantage there.

      RFC_USER="*" shouldn't be required. You can set this as blank as described here:

      Authorization Object S_RFCACL (SAP Library - RFC/ICF Security Guide)

      Cause what you want is executing RFC calls using the same user ID.

      For EAM application specifically you have to assign S_RFCACL to FF IDs in the plugin system as described 1887504 - No SPM Login session created from the SPM Launchpad and there, the RFC user who calls should be the Firefighter from the GRC Box, so there you might need "*" but restrict the rest of the fields... I'm not sure here...

      Hope someone out there can tell us his/her experience with trusted RFCs and if you raise a OSS message please let us know the response you get in order to improve this document. The purpose of this article is to give a overview of the basic steps and, above all, discuss experiences and  improve this document 😉



      • Hi Diego

        Thanks a lot for your quick and detailed reply ! and agree with you that discussion and sharing knowledge will only make all of us better and doesnt harm at all to have a great source of documentation containing lot of information on various aspects of EAM in one place 🙂 -  your inputs give a good pointer with note 1904831 describing the security issues with std. rfc and helps in developing an understanding as to why std. rfcs are being used, with regards to

        (a) s_rfcacl - as per my experience for trusted rfc GRC10 EAM scenario, s_rfcacl has to be assigned to firefighter id in target system with rfc_user field containing the value of the firefighter user who launched it from centralized system - hence -

        "RFC_USER cant be kept blank but has to have user id of the end user - and since any user theoretical can have a firefighter id - its hard to restrict this field as per SAP's usual recommended approach on this object.

        Also RFC_EQUSER field has to be N, becauser user in calling system is end user and wihle user executing the RFC in called (target) system is the firefighter id.

        Which leaves us with the following fields:

        RFC_SYSID: ID of the calling system or the domain of the satellite system

        RFC_CLIENT: Client of the calling system

        RFC_TCODE: Calling transaction code

        RFC_INFO: Additional information from the calling system (currently inactive)

        ACTVT: Activity
        Currently, this field can take the value
        16 (Execute).

        out of this I tried restricting access to RFC_TCODE (to GRAC_EAM and GRAC_SPM) in target system in the role assigned to firefighter id - but it did not work. But this field seems to be most likely field for restriction.

        (b) synch jobs, other admin stuff that needs to be performed from centralized system but fetches data from target system - say for example we had std. rfcs, in that case it would have been the system user and not the current user (i.e the end user - as in trusted rfc per my understanding its usually the end user who authenticates their user id in target system), now this user has to have authorization to fetch the table data and send it back to central system. This means a work that should have been performed by the system user is now being performed end user based on their authorization in target system, so:
        (1) At minimum, GRC admin user id is required in all target systems (just because trusted rfcs are in place ?!)

        (2) You have to worry about identifying authorizations required for data fetching by synch jobs etc. and assign such a role to GRC admin user id in target system.Not denying that nowadays lot of clients dont want to give wide ranging access to system user and want to tie them to a fixed set of authorizations usually being SAP_ALL minus basis and security (at least to start and sometimes to start and end with i.e that is all)

        I hope this the way it will behave if you have trusted rfcs.

        I guess there is a partial workaround - you fix the user who is being used for trusted rfc, have their id created in each target connector, but for case (a) s_rfcacl object still looks for end user who launched ff id session via GRAC_EAM and will not look for this user - even if thats what you have defined in trusted rfc. But in this way - at least you may prevent second case - where you have to create GRC Admin user's id in every system -  in case they run batch jobs that pull data from target systems. Still doesnt suit to think that an end user id has to be created to support a work that should be ideally performed with a system user id. Also this user cant be a non-dialog user - as per my testing done so far because to reason it out - you login into target system using the trusted rfc definition and it opens a dialog session - so it cant open with a system user (but havent verified if thats right)

        Diego/anyone - please review and let me know in case I am missing something, anyone has good way to dealing with these situations. We have raised an OSS on this, will update when we hear back from SAP.

        Many many thanks !!

        Best Regards


        P.S: somewhere in SAP: in rfcs we trust 🙂

        • Many thanks for you input Prashant

          We're currently using decentralized EAM and I think that after SP10 most of the customers do cause is simpler for I didn't have to worry about these RFCs but I'd love to hear from other forum members who experienced that situation.

          Let's us know if you get news from SAP, but anyway discussion has been declared open here meanwhile!   😀



  • Hi Diego - thanks for your inputs - now I see a reason as to why most customers havent faced this issue or this issue hasn't be discussed a lot in SCN. Thanks again for rationalizing this !! .. still lets see how SAP responds and if anyone has a neat way of handling this or if I am missing something obvious all along .. 🙂

    Best Regards


  • Hi Diego & All,

    Allow me to further dig it deep with the authorizations of Firefighter ID, albeit a different topic.

    I am having some concern with the EAM Authorizations concept.

    I am not sure if this has already been covered before - but let me brief you about the issue.

    "GRC EAM Owner is able to assign/maintain any FF ID irrespective of whether that ID is owned by that EAM Owner or not. It doesn't has to be this way, I believe i.e. EAM Owner should only be able to assign the FF ID or maintain the FF ID assignments for only those FF IDs that are owned by them"

    What do you think about the same?

    I have already covered the following below grounds on the same, but to no real help:

    - 1730649 - Firefighter owner can assign ANY Firefighter ID to Firefighter User

    - 1663949 - EAM: Authorization Fixes for Central Owners and Reason Codes and have referred to EAM Authorization

    - EAM Authorization Concepts & Guide

    - GRC AC Latest Security Guide.

    I had also raised an thread for this here.

    Moreover, in the EAM authorization guide, i found this mentioned "The EAM Owner Role can do all available Firefighter ID action for all connector.

    Note: Firefighter Segregation is not available at ID Level; Authorization at connector provides access to available Firefighter ID to the System"

    Any thoughts on this?

    How does it work like in your Landscape?



    • Hello Akshay,

      Actually I don't like that new concept based on authorization objects. I think that the correct option for that would be to check internally if the user is FF owner of such Firefighter ID as in previous GRC Versions.

      The point is that probably most of the customers do not really care about that...Why?? well...usually the FF owners are Managers or Process Owners and they just do not go to GRC to load a user into a table. If you try to explain that to a Manager or a PO he/She would say.."OK, I'm the FF Owner and I'll approve FF ID assignments but I don't want to load the user in the table, that's too 'technical'  for me".

      Then you usually go for an ARQ request to assign FF IDs or a procedure outside GRC that involves the Owner approval but the change itself in GRC is done by a GRC Admin.



      • Hi Diego,

        Couldn't agree any more with you.

        Well that's how the framework of EAM Owner becomes like then.

        If the Owner really cares just about "APPROVING" and would want to avoid "MAINTAINING/ASSIGNING" per se for that regards, then life would be much easier.

        But since in GRC that's how an approval is done (In Case of Workflows for access request haven't been implemented yet), by creating /modifying a row in the table.

        So the way you have explained makes this a bit tricky now.

        Anyways, SAP has also re-affirmed that in newer GRC Version, this check is no more there. The only check which I seem to find is fiddling with the FF IDs which belong to certain connector.

        Much Thanks for your inputs though.



      • As an addition to my earlier comment, there is a Similar suggestion to the above concern at SAP Idea Place.

        I thought to post the link and if you and others feel strongly about it and would promote the same.

        Here is the link to that Idea.

        Please vote up, so that SAP can put it in place.

        Thanks & Regards,


  • HI Diego, guys,

    I have EAM in an Ides environment here where the GRC box is also where the plug-in is loaded.  Everything seems to be set up correctly (parameter 4000 and 4010 maintained), I've assigned the Firefighter ID Controller and Firefighter ID Owner to two different users in the Central Owner section.  Also, I've assigned the Owner to Firefigther ID and Firefighter ID to the user and controller,  Reason codes area also created for that system connector.

    The connector itself is a trusted RFC type.

    But when I start GRAC_SPM as that user, the screen doesn't present any connected systems.

    I've tried adding and then removing the user exits in case that has anything to do with it, restarted several times and nothing appears to be helping.  Very frustrating.

    Any thoughts?

  • Hola Diego,

    Thanks for Mentioning me. Although, I think it was by Anna Otto who initiated that.

    The votes are not doing that good at the Idea Place i guess.

    Also I thought, if you would like to mention this in your blog somewhere around that area --> How this authorization issue of Owners/Controllers can be achieved as an work around.

    I had a thread which ran for quite long and hopefully I had covered out all the issues in that.

    See if you would like to embed it in your link. Gives me a personal contentment that for the time being at least there is a solution we can have in prod environments. See thread

    And for the record, you started compiling this doc. some time 2 years ago and now it has grown quite big with all the info & comments flowing in.. Fast forward 10 years and try to look back at the same piece of information, I shall vaguely remember of yes.. We struggled with that and maybe I ll find myself in bits and pieces, here and there in between the comments somewhere..



    • Hi Akshay!

      Many thanks for you inputs. I've added your thread.

      I now that the document is growing and I try to keep it simple but on the other hand I also want to add new information and improve it, so it becomes quite difficult....and well... in 2024 this thread would make no sense cause by that date SAP would change many things.... I cannot think so forward hahah.



  • Hi Diego,

    Excellent document , very useful information. Controllers are getting the email with the Link to view the log details but no logs appear when the users log into GRC to view the logs using the link. Please see below error. Any help is appreciated.



  • I am working on configuring our EAM system, and this was very helpful, for someone with relatively little experience in SAP this was a great tool!


  • Dear Experts,

    is there a way to move GRC10 transactional data like FF-logs, FF-Assignments, Reason codes, etc. from one system to the other except a systemcopy? (both are GRC10.0) I see many migration guides, but they only covers a migration from CC4.0/5.3 to GRC10.0 and GRC10.1

    Thanks in advance!


    • Hello Andreas,

      I think that you can use the programs provided for the migration. By the way, I've added the document the note 1744929 - Mass Upload of Assignments for EAM that explains how to load mass EAM data using the migration programs.

      In order to download the information from the source system, I guess you might simply look for the ABAP tables were the information is loaded.



      • Thanks Diego,

        in the meantime I got the confirmation, that it is not recommened to transfer the transactional data because of inconsistencies of the created uuids in the tables. In our case we will build the FF Assignments from scratch. I think its the same effort as filling the files attached to the 1744929 Note, or do GRC10 offers the export of EAM assignments?

        Greetings, Andreas

        • Hi Andreas,

          I agree with you. I think the best option is to load the FF assignments manually. Mass load would be useful for a huge number of FF, otherwise it's recommended to do it manually.

          I'm pretty sure that there's no export functionality.



  • Hi, I am working on Decentralized Firefighting and received the following error when trying to firefight from the plugin system "Destination XXXCLNTXXX not maintained when firefighting". I know there's clearly something wrong with the RFC, but what specifically this could be?

    Currently the RFC in the plugin system pointing to the GRC is NO Trusted, logon is specified.

    Previously, we also tested with TRUSTED relationship with logon unspecified.

    If anyone of you experienced the same error before, appreciate your advice.



    • Brenda,

      please check parameter 1000 and 1001 in the plug-in system where you want to start the de-centralized firefighter. After transporting parameters from Q to P this must be changed manually (as destination is now prod and not quality anymore).

      Let us know.



      • Hi Alessandro, thanks for your reply. I already have 1000 and 1001 in the plugin system, thus I believe the error is somewhat related to RFC setup. I have the destination from Plugin to GRC maintained, Logon detailed specified, and the relationship is set to be unstrusted. Because to my understanding, in the decentralized model the connector is only used to retrieve logs, thus it doesn't need to have the trusted relationship. Can someone kindly confirm, and if possible please advise the correct solution if this is wrong.

  • Diego,

    I was just going through your post to solve one of my problem and found your post very informative. Excellent doc and thanks for sharing!

    Unfortunately I could not find any solution for my issue. Any help on following matters?

    1) We have GRC 10 .1 implemented  and both centralized and de centralized FF login is possible. WE can see " Additional Activity" tab enabled but when we click on that it does not open up the reason code window and just make the "logon" tab enabled. What we should do so that additional activity tab pops up for Reason code window with "Document additional Activity " section enabled?

    2) We have plan to use workflow based EAM i.e workflow based EAM is still not in place. Now we are doing all mapping of FF id manually. My question, is that possible that our controllers still get the login notification and Log notification ( with log report attached) in mails ?

    • Hello Kakali

      Thanks for your inputs!

      Regarding the questions, below my comments

      1) The purpose of "additional activity" is to document something AFTER you log in. so this is not enabled when you first login. only after you login you're supposed to add additional comments for things you need to do and you forgot to mention in the initial activities.

      2) you can keep the email notifications with the WF functionality, but there´s no standard option to attach the log in the email as in GRC 5.3. see note 1790583.



      • Thanks for your reply.

        1) Issue is that user is already logged in through FF id ( the traffic light is red i.e. the FF id session is already open ) and then try Additional Activity and instead popping up reason code window , it ends the existing session and Log on tab become enabled.

        2) I will check . Thanx.

        3) Yesterday , face another issue. In DEV GRC box , in ARA reports Filter button is appearing just beside the settings button, but in PRD GRC box , Filter option does not appear . Basis checked that GRC components are same in both environment. Do you have any thought what could be the issue? Both the environment has Technical view as default.


        Kakali Mitra

        • Hi Kakali

          For issue 1, you should check for notes in the marketplace, that´s not the normal behavior.

          For issue 3, my recommendation is to create a new message in SCN. Just for you to start analyzing the issue one of the reasons could be due customized webdynpro using sap-config-mode=X or due to specific user settings.



          • HI Diago,

            Both the issue resolved now . For Filter issue we need to change the UI .

            How ever I come across some other issue in ARM:

            In new access request workflow, Manager is the level 1 approver. I have created one dummy manager and assign ARQ approver role and maintain my email address. When access request submitted , I am receiving the email notification .

            1) If I check in work inbox of Dummy manager , the work item inbox is blank.

            2) If I try to open the link from email notification and try to approve I could see only Close button, nothing else.

            Could you please suggest 1) how I should get the notification in work item and 2) and can see the submit button when approving.

            Appreciate your help!




    Thank you for sharing this useful information.


    I wanted to know if it’s possible to enhance the stadanrd report « Consolidated Log Report  – Transaction Log », « Consolidated Log Report – Change Log » and « Reason Code et Activity Report » in order to add some specific fields to them?

    I have tried to do it by standard custo but it seems that it works only for PC and RM , not for AC …

    DO you have some idea?

    Thanks in advance for your help


  • Thank you for the step by step documents.

    We have a requirement in our organization where FF user type is set as Service and we want to use the FF user id for portal activity, but it doesn't work.

    whether we can use FF user for portal activity with user user type as Service ?


    Sandhya Kotian


  • Hi,

    You have explained the EAM process very clearly.

    Thank you so much!

    In Grc system:-

    After executing the tcode grac_eam and click on login button and giving reason code n is properly directing me to target system where I have my ff I'd.

    But when I goto Nwbc n goto eam launch pad...after giving the reason code n details it us not directing me to target system. Giving error "plan version Current plan was set ".. but still triggerI g emails to controller.

    Can you please suggest!


    Ram V