Roles and permissions in the shop backend

Almost every grown shop has one account that may do everything. It was created years ago because a clean permission cut would have taken longer than a tick next to the administrator role, and nobody has touched it since. The Data Breach Investigations Report 2025 attributes 60% of the analysed breaches to a human element (Verizon, DBIR 2025): mishandling, shared credentials, misused privileges. A permission model does not prevent such mistakes, but it decides how far one of them reaches. This article describes the role cut along the actual tasks, the separation of price, order and customer data rights, logging, the four-eyes principle for prices and discounts, and the procedure for the day an account leaves.

Why every account becomes a full account over time

Permissions tend to grow in one direction only. Somebody covers for a colleague, gets an additional right for it, hands the cover back – and the right stays, because removing it has no trigger. After two or three years most accounts carry the sum of every task their holders have ever had. The 60% quoted above are calculated on a subset of 10,798 analysed breaches; the report explicitly excludes automated cases from that calculation (Verizon, DBIR 2025). The share therefore describes no special case, but the picture of the analysis period from 1 November 2023 to 31 October 2024.

In the shop backend this stays invisible for a long time, because daily work runs more smoothly with too many rights than with too few. It becomes visible only when a price list is overwritten by accident, an export run takes along customer data from an area that is none of its business, or an account that should have ended long ago still signs in. The technical protection of the shop – updates, network separation, encryption – is already in place at that point and still does not help, because the access comes from the inside and is formally authorised. How the individual building blocks interlock is set out in the overview of IT security in e-commerce.

It is also possible that staff who have been transferred to a new department keep their old authorisations and thereby accumulate extensive overall permissions over time.

BSI, IT-Grundschutz Compendium, module ORP.4, section 2.1 (translated from the German original)

The second road into permission chaos is staff turnover without a counterpart in the backend. Operations usually learns about a change later than the HR department, and in some cases not at all. The BSI names this case in the same section: IT operations may receive no information about staffing changes, so that accounts of departed staff are not deleted (BSI, ORP.4, section 2.1). For a shop this means concretely: an account with write access to prices and orders continues to exist, but nobody is watching it any more.

The role cut along the tasks

A durable permission model does not start with people but with tasks. The question is not what somebody should be able to do, but which recurring activities the shop knows and which data areas each of them touches. In a typical retail operation that is five to seven bundles of activity that can be clearly separated from one another. Only afterwards are people assigned to one or more roles – and anyone who needs two roles gets two roles, not a third special role holding the sum of both. That order is the actual trick: it keeps the number of roles small and makes each one describable.

The cut runs along five data areas that have different effects when something goes wrong: catalogue data, prices and discounts, orders, customer data and user administration itself. A badly maintained product text is annoying and corrected in minutes. A wrong price goes straight into sales. A modified order touches accounting and shipping. An export of customer data cannot be recalled. A modified role acts on everything else. The requirement placed on the right that grants access rises in exactly that order. The customer data area can additionally be made smaller instead of merely being secured: where an attribute only has to be confirmed during ordering and not stored, the record whose permissions matter later never arises – how a proof of age or address can be handled that way is described in the article on digital identity proofs with the EUDI wallet.

• Content: write access to texts, categories and media, read access to orders to check the result of their own work, no access to prices and customer data. How the media stock can be kept in order without every role being allowed to delete is described in the article on media management for product images.
• Purchasing: write access to master data and supplier assignment, price changes only as a draft with approval by a second person, read access to orders for demand planning.
• Customer care: write access to orders and customer accounts in the running case, read access to the catalogue, no access to price logic and user administration.
• Accounting: read access to orders, payments and invoice data, write access exclusively in its own document processes, no access to catalogue and users.
• Administration: users, roles, extensions and system settings, but no write access to catalogue, prices and orders. An administration that maintains prices on the side undoes every separation again.
• Reporting: read access to aggregated figures without personal fields. This role is a frequent reason for handing out a full account, and at the same time the one that is easiest to replace.

The role cut has a practical side effect: it makes recurring operations attributable. If the stock correction after the year-end stocktaking is bound to a role, it is clear at the end of the run who touched which quantity – without anybody having to reconstruct the order of events from memory. The same applies to every bulk action that touches many records at once: it is either assigned to a role or it cannot be explained afterwards.

Prices, discounts and the four-eyes principle

Price rights are the area with the shortest distance between mistake and revenue effect. A discount placed on the whole assortment instead of a single category takes effect the moment it is saved, and often becomes visible only in the daily report. That is why this area is the only part of the model that does not belong on a single right but on a procedure: one person creates the change, a second approves it. The BSI lists this split for administrative activities as an exemplary suggestion for elevated protection needs; whether it is appropriate in your own shop follows from a risk assessment.

Administrative activities SHOULD only be able to be carried out by two people.

BSI, IT-Grundschutz Compendium, module ORP.4, section 3.3 requirements for elevated protection needs, requirement ORP.4.A24 (H) (translated from the German original)

In the shop backend this can be mapped in two ways. One separates draft and publication: price changes are created as a scheduled action with a start time, approval is a right of its own and sits with a different role. The other separates scope from amount: whoever may set the discount value does not at the same time decide which quantity of articles it acts on. Both variants cost one additional working step and typically prevent exactly the mistakes that otherwise only revenue reports. How strongly a single parameter carries through into sales is also visible in the shipping cost models, whose thresholds are maintained in the same places.

Logging: who changed what and when

A permission model without a log is a claim. Only the record turns the role assignment into a verifiable statement, and only it makes it possible to distinguish between mishandling, misunderstanding and misuse after an incident. The effort is small, because most backends already produce the data; what is usually missing is the evaluation and a storage location that protects the log from the people whose actions it records.

The important part is separating two levels. Application logs record business changes – which price, which order, which customer account. Server access logs record where a session came from and when. Each of them is incomplete on its own and they only produce a picture together, for example when a price change outside working hours comes from an unknown network. How server logs can be evaluated systematically without drowning in raw data is shown by the logfile analysis – the approach is the same, only the question is a different one.

• Who: the account ID, not the role. Roles change, and the assignment at the time of the change has to be preserved.
• When: a timestamp with time zone. A log in local time without a zone is ambiguous for one hour when the clocks go back.
• What: the field name and the value before it. An entry that records only the new value does not answer the most important question.
• From where: address and session ID. That makes a series of related changes readable as one operation instead of fifty separate cases.
• How long: a defined retention period with subsequent deletion, aligned with the retention obligations of accounting.

Logs do not belong on the same account as the application that produces them. Whoever has write access in the shop should be able to read the log but not to change it; the storage sensibly sits outside the application, for instance in the operating environment with its own permission assignment. For ongoing evaluation, a weekly look at three lists is enough: newly created accounts, changed roles, executed export runs. Everything else is work on demand.

What BSI IT-Grundschutz and NIS2 require

The permission model is not a free exercise. Module ORP.4 of the IT-Grundschutz Compendium describes identity and access management in numbered requirements, several of which apply directly to a shop backend. For companies falling under the NIS2 Directive a statutory level is added; which operations are affected and how that can be determined is set out in the article on the NIS2 Directive for online retailers.

The NIS2 Directive comes at it from the other side: it does not prescribe individual rights but requires in Article 21(2) a minimum set of risk-management measures that member states impose on the entities concerned. Access control appears there in point (i) as a separate item next to human resources security and asset management, with multi-factor authentication following in point (j) (Directive EU 2022/2555, Article 21(2)).

The measures referred to in paragraph 1 shall be based on an all-hazards approach that aims to protect network and information systems and the physical environment of those systems from incidents, and shall include at least the following: [...] human resources security, access control policies and asset management

Directive (EU) 2022/2555 (NIS2), Article 21(2), point (i)

Anyone not covered by NIS2 still has a usable structure in hand, because it places access control in a context with staff and assets rather than treating it as a purely technical question. In practice this viewing angle leads to an operating model that checks every access instead of deriving it from a position in the network – the approach described in the article on Zero Trust for online shops.

Accounts that come from outside

Agencies, temporary staff, the tax office, ERP, marketplace connections: many backends carry more external accounts than internal ones. They are created under time pressure, often during a migration, and are rarely reviewed afterwards because they work. The same three rules apply to them as to internal accounts – need, attributability, time limit – except that here the time limit belongs in place from the start, because the reason for the account has an end.

• One ID per person, service providers included. An agency account used by four people is a shared account with a different label.
• Time limit in the system, not in the calendar. An expiry date on the account withdraws the right even when the deadline is lost in project work.
• Interfaces with their own right. An ERP synchronisation needs write access to stock and order status, but no access to user administration and none to catalogue texts.
• Test systems without real data. An external account on the test system is uncritical as long as no customer data sits there; how that can be achieved is described in the article on Shopware staging without real customer data.
• A second factor for far-reaching rights. The BSI recommends protecting user IDs with far-reaching authorisations by multi-factor authentication (BSI, ORP.4.A10); passwordless methods take the effort out of daily work, as the article on passkeys shows.

The most frequent objection to time-limited accounts is that renewal creates work. It creates less work than an inventory after three years in which twenty external accounts have to be checked for their justification without anybody still knowing the original reason. Anyone having the shop looked after by a Shopware agency can put the time limit straight into the operating routine: an account that expires after the end of an assignment has to be renewed actively – and that renewal is exactly the review that would otherwise have no date.

Implementation in the backend: where it breaks

In the Community Edition, Shopware brings a role system that is granular enough for the cut described: rights are distinguished per area into read, write, create and delete, roles can be composed freely and assigned to a user more than once. What is missing is the interlocking with your own procedure – an approval that requires two different accounts, for example. Additions like that are built as a separate extension within shop programming and stay update-proof that way, instead of migrating into the core as a manual change.

<?php
// Permission profiles as a data set, not as a collection of ticks in the backend.
// A role describes a task and can be explained in a single sentence.

const PROFILES = [
    'content' => [
        'catalogue' => 'write',
        'prices'    => 'no_access',
        'orders'    => 'read',
        'customers' => 'no_access',
        'users'     => 'no_access',
    ],
    'purchasing' => [
        'catalogue' => 'write',
        'prices'    => 'draft',          // approval sits with a different role
        'orders'    => 'read',
        'customers' => 'no_access',
        'users'     => 'no_access',
    ],
    'price_approval' => [
        'prices'    => 'approve',        // may not create a draft itself
    ],
];

function may(array $roles, string $area, string $level): bool
{
    foreach ($roles as $role) {
        if ((PROFILES[$role][$area] ?? 'no_access') === $level) {
            return true;
        }
    }
    return false;
}

// Four-eyes principle: drafting and approving may not come from one hand.
function approval_allowed(string $draftAccount, string $approvalAccount): bool
{
    return $draftAccount !== $approvalAccount;
}

Two places break regularly in practice. The first is the extension: a bought or self-built module brings its own rights along, which appear in no role and therefore end up with administration when in doubt. The second is the database: whoever has direct access to it bypasses the role system, because the rights sit in the application and not in the tables. Both places belong in the same overview as the backend roles. Three queries show the current state in a few minutes.

The third query is the most revealing, because it makes the overgrowth visible: a role whose number of rights sits clearly above the others is usually no longer a role but a collection point. The second look goes to the accounts with the administrator flag set, because that flag overrides every role assignment and appears in no role overview. Both figures belong in regular Shopware maintenance, together with the question of which role has grown since the last pass and on what occasion.

When an account leaves

Offboarding is the point where it shows whether the model holds. The BSI puts the requirement briefly: in the event of staffing changes, the user IDs and authorisations that are no longer needed must be removed (BSI, ORP.4.A2). In practice this fails less often on willingness than on sequence – the account is blocked before anybody knows which running cases depend on it, or it stays open because an export is still pending. A fixed procedure solves both, because it prescribes the order.

1. Hand over before blocking. Reassign open cases, scheduled actions and prepared price changes to a receiving role before the account ends. Afterwards the assignment is harder to reconstruct.
2. Deactivate the personal account, do not delete it. A deactivated account keeps the link to past changes in the log. A deleted account leaves a gap there that cannot be closed later.
3. Separate technical accounts. Replace access keys for interfaces that were issued to the person and move them to a named service account.
4. Rotate shared secrets. Renew credentials the person knew that are not tied to an individual – starting with the accounts holding write access to prices, orders and customer data.
5. Count the rights at the end. A short counter-check after departure: does the ID still exist, does it appear in a role, is a session still signing in with it? The result belongs with the date in the record of the case.

Checklist for the permission inventory

A permission inventory is not a project but a recurring date. Twice a year is enough in most retail operations; with high turnover or frequently changing service providers a quarterly rhythm pays off. The pass typically takes two to three hours once the queries from the previous section are prepared, and it can be combined with the remaining operational questions as part of a shop check.

• List every backend account and assign a named person to each; deactivate accounts without an assignment.
• Count administrator flags and justify each account; every justification naming a business task points to a missing role.
• Sort roles by number of rights and check the largest role against its task description.
• Check price and discount rights against the approval procedure: can a single person create and approve?
• Cross-check external accounts against assignment, contact person and expiry date; put a time limit on accounts without one.
• Confirm export rights on customer data individually and limit the scope per right to the fields actually needed.
• File the result with a date and hold it against the previous state on the next pass, instead of starting over.

Where the effort actually sits

The technical part of a role model is done in an afternoon: create roles, assign rights, move users across. The effort sits before and after that. Before, in the question of which tasks the operation actually knows – a question few people can answer off the cuff, because responsibilities have grown verbally and appear in no file. After, in the discipline of mapping every new requirement onto an existing role instead of granting an exception; every exception is the first step back into the state the model was meant to end. Experience shows that a cut carries for about two years before it needs a revision – that is how long it takes for enough new tasks to arise to shift the boundaries. Anyone who plans that rhythm is not running a clean-up operation but a continuation, and that costs a fraction.