Skip to Content
Personal Insights

Amended Lifecycle for SAP S-User IDs (Status: June 2020)

Diesen Beitrag gibt es auch auf Deutsch.

SUMMARY: Starting June 2, 2020, S-user IDs required to access certain SAP webpages will come with an expiry date that administrators can easily extend. Super, cloud and user administrators are not affected, neither are Partner Security Managers and Technical Communication Users.
Of course, the user administrator is still free to simply delete an S-user ID at any time.

To use support applications in the SAP ONE Support Launchpad, purchase software in the SAP Store, or book training courses, customers need a user ID, commonly named an “S-user”. for new customers, SAP creates the first such ID. Afterwards, however, administration of users is completely passed on to the customer.

In the past, these S-users were valid for an unlimited period of time; they had to be deleted manually. Absorbed in everyday life, we might fail to register that colleagues leave the company but take the S-user with them. In principle, this would allow them continued access to internal company information (support tickets, licenses, systems, etc.).

To assist our customers’ user administrators and minimize such risks, starting June 2, 2020, S-user IDs will have an “expiry date”. If the administrator does not intervene – despite early notifications and enough lead time –, an ID will first be deactivated and, in a second step, even deleted.

Super, cloud and user administrators are not affected, neither are Partner Security Managers and Technical Communication Users.

More precisely, the situation is as follows:

  • By default, a brand-new S-user will be valid for 24 months.
    However, a shorter lifespan can be defined in the user request form. This can be an interesting option if, for example, within a project a set end date is known.
  • The shortest possible validity period is 1 day.
  • During the last 90 days the ID holder and administrators will be regularly informed that the S-user needs to be renewed.

Case 1 (most common case):

  • One of the administrators extends the validity of the S-user ID. This time the default is 5 years, which the S-user gets granted with a single click.
  • Optionally, like for brand-new users, an earlier expiry date can be defined. And of course, S-users can be extended at the discretion of administrators long before any notifications have been received.

Case 2:

  • If all administrators ignore these alerts, at the end of the lifetime the S-user’s status changes to Expired. This means that the ID can no longer be used, although an administrator may “revive” it.
  • The S-user is not deleted until a further 90 days have passed without any action by administrators. Once it has been deleted, the ID is for 12 months included in the list of all deleted S-users. Note that it cannot be reactivated, not even by SAP.

Case 2 will only occur if the administrators deliberately ignore all reminders. Usually the reason is that the S-user is indeed no longer needed. Of course, the notification can also be understood as a prompt to immediately delete the S-user manually instead of waiting for its automatic deletion.

All the above actions are performed in the Support User Management application of the SAP ONE Support Launchpad.


On the first day of every month, administrators receive a notification that lists all S-user IDs that are earmarked to expire within the next 90 days. Affected S-users get such an alert 30, 14, and 2 days before the expiry date.

Validity period for existing S-users

As mentioned above, by default new S-users are granted 24 months validity. But what happens to S-user IDs that already exist on the changeover date for the adapted process?

Their validity is initially also limited to 24 months, counted from the last logon date to an SAP website. (For S-users who have never logged on at all, counting starts on the day of their creation).

It could happen that on the changeover day June 2, 2020, an S-user who has been inactive for a very long time is set to Expired straightaway. To prevent this from happening, SAP has made the decision that the earliest expiry date for existing S-user IDs is October 20, 2020. A simple calculation, going back in time by 24 months, shows us that this affects S-users who last logged on before October 20, 2018 (or were created before that date and never logged on). They will start receiving notifications on September 20, 2020. Their administrators will be alerted even earlier: on August 1, September 1, and October 1, 2020.

(Click to enlarge image)

You must be Logged on to comment or reply to a post.
  • Hello Peter,

    thanks for this advance information.
    But what about the user administrators, will they expire as well? Who is entitled to extend user administrators?

    Thanks, Roland

    • Dear Mr. Koethnig,

      Good point, and indeed I had omitted this small, but important, detail in my blog post. Super, cloud and user administrators are not affected by the process change, neither are Partner Security Managers and Technical Communication Users. I have corrected the blog post accordingly. Thanks for pointing this out.

      Best regards, herzliche Grüße,
      Peter Kappelmann

  • Hello Peter,


    Thanks for your article, these are good news for administrators.


    We have a doubt about S-user deletion: What happen with incidents created by an S-user after this user is deleted? (being them open or yet closed).



    Pedro Restrepo


    • Hello Pedro,

      Whether the user is auto-deleted (because the lifespan didn't get extended) or manually deleted, the implications are always the same: Objects associated with the user ID are not affected. In particular, incidents reported by the user can still be found using the incident search or in the incident inbox (My Company's Incidents), and colleagues with the appropriate authorizations can work on behalf of the (now deleted) reporter.

      Best regards,

  • A step in the right direction, thanks for that! Really good.

    Lets think further ahead: What about an integration into an IDM system or providing any kind of API for identity and access handling from the outside? Or at least enhancing the mass maintenance functionalities?

    That would give a dramatically good possibility to manage and govern S-users even better than today.

    Thanks and regards

  • This implementation of this functionality goes a step far.

    • It is correct to implement a function that allows us as user / super admins to set a validity date.
    • This is useful for external consultants / project work.
    • but I don't want to set this by default to e.g. 24 month
    • I want to keep all other users unlimited valid
    • Especially when I have administrators who work on weekends I must avoid that they loose their s-user by chance
    • I don't want to have a mandatory process in place that Forces me as a customer to renew the validity date on a regular Basis (this will NOT improve any Security / LifeCycle aspect) and it makes it complex to differentiate between the users that should get invalid (see first Point) and the ones who need a renewal by default.

    It is also true, that a cleanup of users who have not logged on since xy month is a useful function. But thsi should not be linked with the validity of the account.

    • Let the function that you describe for the go live be avilable on demand for the super / user admins and have it customizable for own purposes.
    • what do you do with bounced emails (starting with out-of-Office, changed email up to not existent)?
    • once this function is in place, you could ask all the super / user admins to execute it on a regular Basis and you will see, that the total count of S-Users on your platform will decrease dramatically.
    • At AXA I implemented such Kind of logic on my own and I came down from originally more than 900 users to around 330 S-Users.

    Please consider to modify the process. We will discuss the topic also during the DSAG User Group Meeting mid March.

    Best wishes,



    • Dear Detlev,

      Thanks for sharing your feedback and concerns. Perhaps some details haven't become clear from my blog post:

      • The default expiry date for new S-user IDs is 24 months. However, if you want to extend the validity of an existing S-user, you can choose anything between one day and 60 months.
      • Notifications about expiring S-users will be sent out three months in advance and on a regular basis thereafter (with daily reminders in the last days before expiry). They will be sent to the owner of the ID and all administrators who are entitled to extend its validity. I think that it is rather unlikely that after all these warnings an ID gets auto-deleted at a critical point in time, e.g. on an upgrade weekend. It's also unlikely that all these notifications will bounce.
      • There is no plan to regularly delete S-users automatically based on their last logon date. Only at the start of the new process, when we have to specify a default expiry date for already existing S-users, their last logon date is one of the parameters.
      • Having said this, it could become a useful feature -- as you suggested -- to let administrators mass-delete S-users that haven't logged on for while. While this is not part of the project, we can discuss this and add it to our backlog. A "Last logon" filter in the list of users, combined with the existing "Delete" feature, would do the job.

      Perhaps it makes sense to schedule a call to explain the process in more detail and clear up potential misunderstandings.

      Best regards,

  • Peter Kappelmann thanks for this blog.  My question is relating to S-user IDs that was obtained via SAP certification.  What happens to those? I'm in such a scenario, even though I had my S-user ID after completing my certification, my S-user IDs is still tied to the company where I was working at that time (and no longer work there). I would assume they wouldnt be encouraged to extend such S-user IDs.  What are our options?



    • Hello Chandra,

      In actual fact, when you left your previous employer, they should have deactivated your S-user ID straight-away. It is linked to company data, so your new employer should generate a new ID for you that you can work with on their behalf (assuming they are an SAP customer or partner).

      I don't expect you to alert the previous company about the fact that you still have got an S-user ID associated with them. 🙂 But there is no option for you to get that ID extended, I am afraid. An S-user ID is tied to an SAP customer company, and if that link ceases to exist, the ID should be deleted. If not immediately, then eventually by expiring.

      Please note that SAP offers SAP Universal ID ( as your personal ID. If you have got an S-user ID, you can link it to your UID and use UID to log on to websites that usually require an S-user ID. But this won't prevent the S-user ID from expiring, so eventually this option will be gone. Still all data related to your UID (like blog posts) will continue to exist. "Only" an action log of activities related to your S-user ID, i.e. activities you performed on behalf of a company (incidents, keys etc.) will be gone.

      Best regards,

      • Thanks Peter and appreciate the details.  I understand the linkage between S-user Id and the company.  However the issue was caused by SAP by wrongly tying my SAP certification to the S-user Id associated with the company (both were issued at the same time). The S-user Id should have been tied to the SAP certification only and not to the company but somehow, someone in SAP tied these two together and I'm paying the price for it.



        • Dear Chandra,

          I agree that it shoud be possible to associate your certification with your SAP Universal ID / email address rather than your S-user ID. Have you spoken to someone from SAP training? Phone numbers for a variety of countries are listed at I hope this helps.

          Best regards,

          • Yes, they couldnt find my SAP certificate in their database as they only have from the last years I believe.  My SAP certification is from 2005, so they couldnt help.


  • Hello Peter,


    what about the S-User of customers who are served by a partner (like VAR).

    The S-Users which are replicated to our ticketsystem after they were created in SAP Support Launchpad normally act only in the partner portal (ticketsystem).

    And also the S-Users for ticket replication to our ticketsystem never will log on to the Launchapd.


    The deactivation of this S-Users will be a massiv interruption in supporting our partner customers.


    Regards Markus

    • Hello Markus,

      The new rules for an S-user ID’s lifecycle apply to all S-user IDs (except super, cloud and user administrators, Partner Security Managers, Technical Communication Users), regardless of how they were created or in which context they are used. Their last logon date will be tracked across SAP websites, so the fact that the S-user IDs that you mentioned never logged on to the SAP ONE Support Launchpad will not have any impact on their default expiry date: Assuming that they have recently been used, these IDs won’t expire anytime soon.

      However, within the next two years, they will be earmarked for expiry/renewal. Like for all other S-user IDs, all administrators who are entitled to extend them, will be notified well in advance.

      If some S-user IDs are exclusively used for system-to-system communication between customer, partner, and SAP systems, it may be worthwhile to step-by-step replace them by Technical Communication Users, which are not affected by the new rules and processes.

      Best regards,

      • Hello Peter,

        your last sentence raised my attention, you mentioned to use Technical Communication Users for system-to-system communication between customer, partner, and SAP systems instead of S-users.

        Please give some more details on scenarios where "normal" S-Users can be replaced by Technical Communication Users.

        What about S-Users used in LOP - Semi Automatic Line Opener Program scenarios (SAP Note 797124) currently requiring a "normal" S-User ("In order to communicate with the Service Backbone the LOP needs to authenticate itself. This can be done by using valid user credentials (S-User-Id and password)")

        Thanks Roland

  • Hello Peter,

    it's regarding S-user expiry notification,

    I have received S-user expiry notification as administrator from SAP stating that "Check the list of 2 S-User IDs that expire in the next 90 days" in GERMAN Language.below are the my queries.

    1.can we get notification in English instead of German? or notification in multiple languages? since lot of our S-users aren’t able to understand the German language.if yes, how to change the notification language?

    2.can we include the S-user ids instead of number of s-user id(list of 2 S-User IDs), so it's easy to identify for which s-user the notification received.


    • Hello Appala,

      Unfortunately, there is a bug in the notification that shall alert admins about S-user IDs that are about to expire within the next 90 days, and all emails are sent in German. Our team is looking into this issue and will hopefully fix it soon. Afterwards, emails will reflect the admin's preferred language as specified in the SAP ONE Support Launchpad user profile.

      Your second request, to include the list or provide a direct link to the list, is on our radar. Please keep in mind that the list could change: By the time that you log on to the launchpad, other admins might have taken care of some expiring IDs. So a static list in an email might no longer reflect the facts.

      Best regards,

  • Hello Peter,


    What about S-Users issued by One Time Training Customers? I have my S-user since 2003 when I went through SAP Academy and got my certification.

    Will SAP automatically renew those S-Users? Or do I have to use that request form within the User Profile Page?





    • Hello Leandro,

      All S-users (except administrators), regardless of how they were generated or obtained, now have an expiry date, including yours. You can reach out to your admins at and ask them to renew the ID. Furthermore, you and your admins will be notified before the expiry date. So hopefully you can keep that S-user ID.

      SAP will not interfere with S-user administration as these IDs are owned by our customers.

      Best regards,

  • Hi Peter,

    The Support Portal information states: "You may extend an existing user for the required length of time (min 1 day, max 60 months)."

    However when my customers and myself have tried to make updates to multiple users with ID's that don't expire until later in 2020 or in 2021, the manage expiry date option is greyed out.  They updated the users who were set to expire Oct. 20, 2020.  Then they're trying to update the other existing users with ID's expiring later to have the same expiry date as the ones they just updated expiring Oct. 20, 2020.

    Ideally then they would have one expiry date and therefore could go in and choose all those with the same dates and update them all at once.  That doesn't seem to be an option right now.

    • Hi Christine,

      For governance reasons, extending the lifetime for multiple S-user IDs comes with a few restrictions. For instance, mass updates are only possible for S-user IDs in status Expiring or Expired. A maximum of 500 S-user IDs can be extended, by a time span between 1 day and 12 months.

      As the cut-off date for the new process is in October 2020, at the moment there may be a few more exceptions where IDs cannot be extended the way you'd like to. If I remember correctly, it is not possible to give an expiration date sooner than mid-October.

      More information can be found in SAP KBAs 2931034 and 2930885.

      Best regards,