The STRUST authorization object controls access to SAP system trust settings

In SAP S/4HANA, the STRUST authorization object is what controls who can view, create, and modify system trust settings. This object gates access to the transaction STRUST itself, which is where administrators manage digital certificates, certificate authorities, and SSL/TLS configurations that the system uses to communicate securely with external systems.

If you need to work with certificates or trust relationships in your SAP environment, you will need STRUST authorization. Without it, the transaction will not open, and you cannot make changes to how your system validates or establishes secure connections with other applications.

Key Takeaways

  • STRUST is the authorization object that controls access to the STRUST transaction, where certificate and trust settings are managed.
  • The object typically includes activities like display (activity 03), create (activity 01), and change (activity 02) that determine what users can do once they access the transaction.
  • Certificate management is a sensitive operation, so STRUST authorization is usually restricted to system administrators and security teams.
  • If a user cannot open STRUST, the missing authorization is almost always STRUST with the appropriate activity value.

How STRUST authorization works in practice

When a user tries to open transaction STRUST, SAP checks whether their user account has the STRUST authorization object assigned. The system looks at both the object itself and the activity code attached to it. Activity 03 allows display only, activity 02 allows changes, and activity 01 allows creation of new trust entries.

A user with STRUST and activity 03 can view all certificates and trust relationships but cannot modify them. A user with activity 02 can change existing entries. Most administrators receive activity 02 or 03, depending on whether they need to actively manage certificates or only monitor them.

Where STRUST appears in the authorization system

STRUST lives in the SAP authorization system alongside other security-related objects like TCODE (transaction access), PFCG (profile authorization), and RFC1 (remote function call access). You assign it through role maintenance in transaction PFCG, where you add the object to a role and specify which activities are permitted.

The object is not tied to a specific module like Finance or Logistics. Instead, it applies system-wide, because certificate management affects how the entire system communicates with external partners, payment processors, and cloud services.

What happens when STRUST authorization is missing

If a user lacks STRUST authorization, they will see an authorization error when attempting to open the STRUST transaction. The error message typically reads "You do not have authorization for this transaction" or similar language depending on your SAP version and language settings.

The user cannot view certificates, cannot change trust settings, and cannot troubleshoot SSL/TLS connection problems. In many organizations, this is intentional — only a small group of administrators should have access to certificate management because misconfiguration can break integrations and block critical business processes.

Related authorization objects for certificate and security work

STRUST is the primary object, but certificate work sometimes involves related authorizations. RFC1 controls remote function call access, which is often used alongside certificate management for system-to-system communication. TCODE controls access to individual transactions, so if STRUST is restricted, users cannot reach the transaction even if they have the object assigned.

If you are setting up a role for a security administrator or integration specialist, you may need to combine STRUST with objects like S_DEVELOP (for development work), S_ADMI_FCD (for function module access), and PFCG (for role administration itself). The exact combination depends on what the person needs to do.

How to check and assign STRUST authorization

To see whether a user has STRUST authorization, open transaction PFCG and search for the user's role. Look at the authorization data and search for the STRUST object. If it is not there, you need to add it.

To assign STRUST, edit the role in PFCG, go to the Authorizations tab, and add the STRUST object. Specify the activity code (usually 02 or 03), then save and generate the role. The user will have access after they log out and log back in, or after the system refreshes their authorization cache.

If you are not sure what activity level to assign, start with activity 03 (display) and escalate to activity 02 (change) only if the person needs to actively manage certificates. This follows the principle of least privilege — giving people only the access they actually need.

Common scenarios where STRUST authorization matters

Certificate renewal is the most common reason someone needs STRUST access. When an SSL certificate is about to expire, an administrator must open STRUST, locate the certificate, and either renew it or replace it with a new one. Without authorization, they cannot complete this task, and the system may lose the ability to communicate securely with external systems.

Integration troubleshooting is another scenario. If a connection to a payment gateway, cloud service, or partner system fails with a certificate error, the administrator needs to open STRUST to check whether the certificate is valid, whether it is trusted, and whether the certificate chain is complete. Display-only access (activity 03) is often enough for this work.

Setting up new integrations sometimes requires adding a new certificate or trust relationship. A developer or integration specialist may need STRUST with change activity (02) to configure the system to trust a new external system's certificate.

Frequently Asked Questions

What is the difference between STRUST and TCODE authorization?

TCODE controls whether a user can see and open a transaction at all. STRUST controls what the user can do once inside the STRUST transaction. You typically need both: TCODE to reach the transaction, and STRUST to perform specific actions within it. If either is missing, the user cannot work with certificates.

Can I give someone STRUST access without making them a full system administrator?

Yes. Create a role with only STRUST and activity 02 or 03, plus any other objects they need for their specific job. Assign that role to the user. They will have access to certificate management without having broad system administration rights. This is the recommended approach for security and compliance reasons.

What happens if I assign STRUST with activity 01 instead of activity 02?

Activity 01 is for creating new trust entries from scratch. Activity 02 is for modifying existing ones. In practice, most administrators use activity 02 because they are usually updating or renewing existing certificates rather than creating entirely new trust relationships. Activity 01 is less common and should be assigned only when someone specifically needs to add new certificate entries.

How do I know if a user's STRUST authorization has expired or been revoked?

Authorization objects do not expire on their own. If a user previously had STRUST access and now cannot open the transaction, either their role was changed, their user account was deactivated, or the role was regenerated without the STRUST object. Check the user's current role assignment in transaction SU01 and verify that the role includes STRUST with the correct activity.

Is STRUST authorization the same across all SAP systems?

The STRUST object exists in all SAP systems, but the specific activities and restrictions may vary depending on your SAP version and customization. Some organizations also create custom authorization checks on top of STRUST. If you are moving between systems or environments, verify that the role you are using includes STRUST with the activity level you need.