How not to overdo authorizations? - Least Privilege Principle in SAP

In the world of ERP systems like SAP, user authorizations are a critical factor for both security and smooth business operations. Yet surprisingly often, users end up with far more access than they actually need. Sometimes "just in case," sometimes "because it was quicker." And sometimes simply because no one bothered to verify it. There is, however, a principle that should form the foundation of any authorization management policy: the Least Privilege Principle (LPP). In short - users should only be granted the access strictly necessary to perform their business tasks. Nothing less, but also nothing more. The scale of the problem is illustrated by a study conducted across 225 organizations: as much as 85% of assigned authorizations were not used during the last 90 days, and 1 in 3 users had access to systems they hadn't logged into at all. These numbers highlight how often excessive access is granted by default or forgotten during role changes. And every such access means a potential risk: of data leakage, fraud, error, or compliance violations.  

Why is it so important?

The LPP is not just a best practice. It is one of the pillars of information security and regulatory compliance. Granting overly broad authorizations can lead to:

• financial fraud and data manipulation,
• accidental errors resulting in data loss or process disruption,
• violation of segregation of duties (SoD),
• non-compliance with regulations (e.g. GDPR, SOX),
• more difficult audits and a larger attack surface for cybercriminals.

 

Real-life stories: what it looks like in practice

Let's take a look at several examples where the Least Privilege Principle was not applied: Example 1: Accounting employee with full access to the invoicing cycle An employee in the finance department had access to all transactions within the invoicing cycle: from entering incoming invoices (MIRO), through document posting (FB60), to payment approvals (F110). Risk: The employee could independently complete the entire process - from document creation to executing the payment. This level of access violates the segregation of duties principle and makes it significantly harder to determine who was responsible for which part of the process. Solution: Limit access to one role only - e.g. either MIRO or FB60 - and assign payment approval to a different user. It's also worth implementing a workflow and clearly defining ownership of each stage of the process. Example 2: Purchasing employee with access to sales conditions An employee in the purchasing department had access not only to purchase orders (ME21N, ME22N), but also to sales pricing conditions (VK11). The problem? This data wasn't needed for their role, and editing it could have strategic consequences. Risk: Unauthorized modification of pricing policy - either accidental or intentional. Solution: Clearly separate purchasing and sales roles and limit access to data strictly within relevant organizational units. Example 3: Employee after a role change After transferring from the warehouse to the controlling department, the employee retained their old authorizations and received new ones. The result? Simultaneous access to warehouse documents and cost-related data. Risk: Excessive access to processes outside current responsibilities; potential SoD (Segregation of Duties) conflicts. Solution: Each role change should trigger a full access review - not just adding new roles but also removing those no longer needed. These examples show how easily excessive access can be granted - often due to haste, lack of periodic reviews, or careless role combinations. Each of these cases highlights how even seemingly minor oversights can lead to serious risks that are easy to eliminate by applying the LPP.  

How to apply the LPP in practice?

Applying the Least Privilege Principle requires not only awareness of potential risks but also concrete organizational and technical actions - ideally implemented systematically and with long-term security in mind. Here are some suggestions:

• Design business roles based on the actual scope of responsibilities - without unnecessary transactions.
• Define organizational fields and limit data access (e.g., to a specific company code or warehouse).
• Use structured approval and review processes - especially during role or position changes.
• Verify SoD (Segregation of Duties) conflicts before granting access.
• Recertify user access regularly, e.g., every 6 or 12 months.
• Leverage SAP tools such as GRC Access Control, SUIM, ST03N, or transaction logs.

If you want to truly streamline access management, it's worth investing in dedicated solutions like smartGRC (https://smartgrc.eu/). These tools allow you to:

• conduct periodic access reviews,
• Implement workflows for access request and approval processes,
• manage a SoD risk database, which significantly improves control and enhances the security of your SAP environment.

 

LPP and user convenience

A common myth is that limiting user access makes work less convenient. In reality, it's quite the opposite. Well-designed roles - aligned with actual responsibilities and stripped of unnecessary transactions - help users:

• find the functions they need more quickly,
• avoid being overwhelmed by unnecessary interface options,
• make fewer mistakes caused by clicking "the wrong thing."

The Least Privilege Principle improves not only SAP system security but also its usability. It creates a cleaner, more intuitive interface - resulting in a better experience for the end user.  

LPP and security standards & regulations

It's also important to remember that the Least Privilege Principle is not just a good practice - it is a formal requirement in many international standards and data protection regulations. Here are a few examples:

• ISO/IEC 27001 - requires access to be granted based on business need.
• NIST SP 800-53 - identifies the least privilege principle as a foundational control for protecting IT systems.
• RODO/GDPR - enforces data minimization, meaning access to personal data must be restricted to those who truly need it.
• SOX (Sarbanes-Oxley Act) - mandates access control to ensure the integrity of financial reporting.

Following the LPP not only minimizes operational risks but also helps maintain compliance with applicable laws and standards - which is often critical during audits and external inspections.  

What do you gain by applying the LPP?

Implementing the Least Privilege Principle is not just about compliance and security. It also brings a number of practical benefits:

• Fewer audit issues - thanks to better control over access rights.
• Faster and more transparent reviews - well-structured roles mean fewer exceptions to explain.
• Lower access management costs - fewer roles to maintain, fewer IT support requests.
• Greater transparency of responsibilities - it's clear who is responsible for what.
• Fewer user errors - because users only have access to what they truly need.
• A "cleaner" SAP system - no oversized roles or outdated permissions lingering in the background.

 

In conclusion - common sense as a standard

The Least Privilege Principle is not about excessive caution - it's a professional approach to SAP security. It protects not only data and processes but also the organization's reputation. That's why it's worth taking a moment to ask: Is this access truly necessary? If the answer is no - that's the perfect moment to reduce it. References

1. Cloud Security Alliance. (2024). Mastering least privilege: Cutting unused access without cutting corners. Retrieved from https://cloudsecurityalliance.org/blog/2024/05/30/mastering-least-privilege-cutting-unused-access
2. (n.d.). What is least privilege? Retrieved from https://www.cyberark.com/what-is/least-privilege/
3. Edwards, M. (2025). Annex A.5.3: Segregation of duties. ISMS.online. Retrieved from https://www.isms.online/iso-27001/annex-a/5-3-segregation-of-duties-2022/
4. National Institute of Standards and Technology (NIST). (n.d.). Least privilege. Retrieved from https://csrc.nist.gov/glossary/term/least_privilege
5. (2024). Secure SAP with effective access governance. Retrieved from https://www.safepaas.com/articles/secure-sap-with-effective-access-governance/
6. (2025). Hozzáférés-tanúsítás: a végleges útmutató. Zluri. Retrieved from https://www.zluri.com/blog/access-certification
7. (2024). Official smartGRC product site. Retrieved from https://smartgrc.eu/