In short and in plain language
Logins to your shop are created for good reasons. But they often stay when nobody needs them any more. Such old logins are dangerous.
They are not only in the admin area of the shop. They are also with your domain provider, your payment service or on the server.
The article shows how to keep a list of all logins. It also shows how to remove logins when someone leaves.
We keep this list as part of the maintenance contract and check it on fixed dates.
The open access path that ends up hurting a shop the most usually belongs to nobody any more. It was created three years ago for a data migration, has had no owner since, and appears on no handover list. Whoever goes looking for it rarely finds it in the backend: it sits with the registrar, in the payment account, or as a deployment key on a server that two people believe was switched off. This article describes how an access inventory comes about, how an offboarding sequence works that does not stop at the backend login, and how to tell whether the revocation actually took effect.
Key takeaways
- Access is created with a reason and disappears without one. 48 percent of all analysed breaches involved a third party, an increase of 60 percent over the previous dataset (Verizon DBIR 2026).
- In retail the share is higher than average: 68 percent of breaches involved a third party and 58 percent a human element, drawn from 997 incidents and 806 confirmed disclosures (Verizon DBIR 2026).
- In Germany, 55 percent of affected companies name inadequate identity and access management as a reason why an attack caused damage at all (Bitkom).
- Revocation is a requirement, not a nice-to-have: when staff changes occur, user IDs and permissions that are no longer needed must be removed (BSI IT-Grundschutz Compendium 2023, ORP.4.A2).
- Weak passwords and permission misconfigurations stay open particularly long: resolving half of those findings took almost eight months (Verizon DBIR 2026).
The access nobody sees any more
A shop grows through access. A database user is added for the migration, an API key for the price feed, an SSH account for troubleshooting, a backend login for the agency running the campaign. Every one of these steps has a reason, and every one is needed at the moment it is created. What regularly goes missing is the counter-step: the point at which that same access disappears again. This imbalance is the actual finding. Access is created under time pressure and with a clear reason; it disappears under neither.
The order of magnitude can be quantified. The Verizon dataset covers more than 31,000 security incidents and more than 22,000 confirmed data breaches involving organisations in 145 countries (Verizon DBIR 2026). 48 percent of those breaches involved a third party, an increase of 60 percent over the previous dataset (Verizon DBIR 2026). In retail the figure is higher still: 68 percent of the breaches analysed there involved a third party and 58 percent a human element; the industry section covers 997 incidents, 806 of them with confirmed disclosure (Verizon DBIR 2026).
The German picture matches. In a survey of 1,003 companies with ten or more employees, 55 percent of affected companies name inadequate identity and access management as a reason why an attack led to damage at all (Bitkom). Among the companies that fell victim to data theft, industrial espionage or sabotage, current or former employees appear as a source with 23 percent acting unintentionally and 19 percent deliberately, customers and suppliers with 8 percent each (Bitkom). Access held by someone who once belonged is therefore not an edge case but one of the main tracks.
Revoked is not the same as revoked
Time is a factor too. Only 23 percent of the third-party organisations analysed had fully remediated missing or improperly secured multi-factor authentication on their cloud accounts; half of all findings were resolved within a month (Verizon DBIR 2026). For weak passwords and permission misconfigurations, resolving half of all findings took almost eight months (Verizon DBIR 2026). A permissions problem is typically not an event with a date but a condition with a long half-life.
The access inventory: ten places, not one backend
An access inventory is not a user list. A user list answers the question of who can log in to the shop backend. The inventory answers the question of who can change, read out or shut down the shop – and by which route. In a shop that has grown over the years, that second question typically has more than ten answers, exactly one of which lives in the backend. The list below is the frame we work through during a stocktake.
| Access route | Typical holders | What revocation means |
|---|---|---|
| Shop backend | Editorial, agency, support | Deactivate the account, end open sessions, review the role |
| Server via SSH | Hosting, development, deployment | Remove the public key, lock the system account |
| Database | Application, reporting, legacy data | Remove the user, limit rights to the application |
| DNS and registrar | Agency, IT management | Cut off access, move ownership to your own company |
| Payment account | Accounting, management | Remove the user, verify the stored payout account |
| Shop API access | ERP, feeds, marketplaces | Invalidate keys, check the origin of the calls |
| Mail delivery | Marketing, transactional mail | Change the credentials, review sender authorisations |
| Code repository | Development, service providers | Withdraw membership, replace deployment keys |
| Monitoring and alerts | On-call, agency | Update the recipient list, look for silent forwards |
| Backups | Hosting, incident team | Revoke access to the storage location, test the restore |
The right-hand column is where the actual work sits. Deactivating an account takes seconds; working out which public key in which file belongs to which partner takes longer. Anyone who has documented server and PHP hardening once will find these places again much faster, and anyone who treats rotating API keys and secrets as routine has already covered half the distance when it counts.
- Access route – not the name of the person, but the system and the type of access: user account, key or integration.
- Accountable role – who inside your own company decides whether this access stays. Without that field, the entry is orphaned at the next staff change.
- Reason – why it exists. Access with no nameable reason is the first candidate for revocation.
- Date of the last review – without this field the inventory becomes an assumption with a timestamp after a year.
The review date turns a list into evidence
Roles instead of names: accountability makes revocation verifiable
Manage access by names and every change becomes a search task. Manage it by roles and every change becomes a deletion. The difference only shows up when it matters: a role has a purpose, a scope and an accountable person inside your own company; a name has none of that. That is why a usable inventory puts the role in the row and the person in the column – and why a second factor on a role with far-reaching rights is not a luxury. How to put that in place is covered in hardening shop administrator access.
Role instead of person
Editorial, agency, hosting, accounting: four roles with different scope. Whoever leaves loses the role, not just an account.
One access, one purpose
One key for deployment, another for troubleshooting. Shared access cannot be revoked selectively when someone leaves.
Attributable user ID
Shared mailboxes such as editorial@ or agency@ prevent any later attribution. Every user ID belongs to exactly one person.
Named accountability
Every entry has a person inside your own company who decides on its existence and revocation – independently of the provider.
Least privilege
Rights are granted according to actual need. Access that can do less leaves fewer leftovers when it is revoked.
A date, not a reminder
Revocation hangs on a date in the calendar, not on the memory of the person who set the access up.
The principle is not up for discussion: user IDs and permissions may only be granted on the basis of actual need, and when staff changes occur those no longer needed must be removed (BSI IT-Grundschutz Compendium 2023, ORP.4.A2). For that revocation to be visible afterwards, every change to permissions belongs in the same evaluation as logins and errors; what that looks like in practice is described in the article on log monitoring and alerting.
The offboarding sequence in seven steps
An offboarding process that works is boring. It consists of a fixed sequence that runs regardless of whether someone leaves on good terms or in a dispute. That independence is precisely the point: the sequence must not depend on what the relationship looks like on the last day. For the unplanned case the same sequence applies with shorter deadlines – the preparation for that is in the emergency plan for a hacked website.
- Record the trigger. Date, reason and the role that ends. Without this entry, the sequence does not start in a traceable way.
- Pull the inventory. All entries pointing at the ending role – across all ten access routes, not the backend alone.
- Handover before revocation. Knowledge, responsibilities and ongoing work pass to the successor before the access ends.
- Revoke and document. Per entry: revoked on, by whom, with what result. An empty result field counts as open.
- Change shared secrets. Everything the departing role could have known is replaced, not only what was assigned to it.
- Run a counter-check. A second pass through the inventory, carried out by someone other than the person who revoked.
- Record the closure. Whatever stayed open is logged with a reason and a date. Silence is not a closure.
The order is half the benefit
The departure of employees is a regulated process too, not something arranged in passing: departing employees must return all documents, keys and devices received in the course of their work, along with identity cards and access authorisations (BSI IT-Grundschutz Compendium 2023, ORP.2.A2). For a shop there is a second question that is often overlooked: who informs customers if something tips over during revocation? The article on the status page for outages describes the channel that should already be in place for that.
Changing providers: what contract and regulation require
When a service provider changes, a legal dimension is added to the technical one. Anyone processing personal data on your behalf is a processor, and the contract covering that expressly regulates what happens at the end. The regulation frames this as an obligation of the processor and gives the controller the choice between deletion and return.
at the choice of the controller, deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies unless Union or Member State law requires storage of the personal data
The same article requires the processor to make available to the controller all information necessary to demonstrate compliance and to allow for audits (GDPR, Article 28(3)(h)). And Article 32 requires a process for regularly testing, assessing and evaluating the effectiveness of the technical and organisational measures (GDPR, Article 32(1)(d)). An access inventory with a review date is exactly that process in readable form – and backup retention belongs with it, as the article on GDPR-compliant backup retention shows.
- Decide on return or deletion in writing. The choice lies with the controller; without a decision, the data simply stays with the old provider.
- Track the provider's access separately. People at the provider, technical accounts of the provider and its subprocessors are three different rows.
- Keep instruction-bound processing in mind. Controller and processor take steps to ensure that people under their authority with access process the data only on instructions (GDPR, Article 32(4)).
- Collect the evidence while the line is still warm. After the final invoice, willingness to provide information tends to drop.
- Check continuing obligations. Where retention periods apply, documented blocking replaces deletion; that belongs in the same row as the revocation. Which updates hang on this is shown in the overview of data protection updates.
The module for third-party operation covers this too
What remains after revocation
Revoking an account ends the login, not necessarily the access. An open session continues until its time window expires. An API key hangs on an integration, not on a user account. A webhook keeps pointing at an external target even though the person who created it left long ago. These three leftovers are why offboarding without a counter-check is only half the job. They can be avoided if the inventory carries them as rows of their own from the start.
# Extract: one system, three access routes, one row each
system: shop-backend
purpose: Maintenance of product data and orders
access:
- role: editorial
type: user-account
accountable: marketing
last_review: 2026-07-14
state: active
- role: agency
type: user-account
accountable: it-management
last_review: 2026-07-14
state: active
- role: integration-erp
type: api-access
accountable: it-management
last_review: 2026-04-02
state: review
note: key without a named reason since the migrationThe file is deliberately plain. It sits next to the rest of the operations documentation, is updated with every change, and is therefore, in case of doubt, the only place where the target state is written down. In Shopware maintenance we keep one per instance, because integrations and deployment routes rarely match between two shops.
- Open sessions. A deactivated account with a running session stays capable of acting until the session expires or is actively terminated.
- Integrations and API access. They hang on the system, not on the person. After revocation, every integration of unclear origin belongs on the review list.
- Webhook targets. Outbound messages to external addresses typically survive a staff change because they appear in no user list.
- Second factors and recovery codes. A registered device or a printed code is an access route of its own with a row of its own.
- Notification paths. Alerts going to a departed address are a silent failure of monitoring; the obligations attached to this are placed in context in the article on NIS2 obligations for online shops.
Recertification: the evidence that it holds
Recertification means a named person confirming, on a given date, that every entry in the inventory is still needed. This is not an audit and rarely takes more than an hour for a mid-sized shop. The benefit is that access thereby acquires an expiry date without anyone having to cancel it. The counter-check is more reliable through the systems themselves than through the memory of the people involved.
Three commands, three findings: a key from 2023 with no named reason, a database user with access from any address, and a webhook reporting order data to a former partner. None of these three shows up in the backend user list. The appointment for this belongs in the same calendar as the other maintenance windows – and that calendar moves twice a year, as the article on the clock change with cron jobs and timestamps shows.
- Quarterly for access with far-reaching rights: server access, database, registrar, payment account.
- Every six months for backend roles, integrations and notification paths.
- On occasion whenever a role changes, a project ends or an incident occurs.
- With a result rather than a tick: confirmed, revoked, or open with a reason and a date. Watching this chain continuously belongs in monitoring.
Bringing the inventory into the maintenance contract
An access inventory created only at rollout is paper after twelve months. That is why it belongs where a fixed rhythm already runs. In an SLA maintenance contract the review date sits next to the window for security updates, and both are carried by the same on-call team. That saves no work, but it makes sure the work happens.
Inventory per instance
One record per shop, maintained with every change to roles, integrations and deployment routes.
A fixed review date
Quarterly for far-reaching rights, every six months for the rest – with a named person and a written result.
Offboarding on call
A prepared sequence for the planned change and the same sequence with short deadlines for the unplanned case.
Which of this belongs to which service is set out in the overview of maintenance services. If you are not sure how many access routes are open in your shop, the stocktake is the first step: we pull the record across all ten routes, flag the entries with no nameable reason and propose a review rhythm. The way there runs through the contact form.
The question that reveals the state
Sources and studies
Related Articles
Shop Server Logs: How Long IP Addresses May Be Stored
How long may IP addresses stay in server logs? What the GDPR requires, what the five weeks from the BfDI mean, and how rotation, truncation and backups fit in.
WordPress security updates: what old branches still get
WordPress 7.1.2 closed a critical flaw and the fix was backported to 4.7 as a courtesy. What older branches receive, what they do not, and when to move up.
Discount codes in Black Week: detecting abuse early
Discount codes in Black Week: code length, a rate limit at the coupon field, alerts on failed attempts and new-customer discounts that resist multiple accounts.