The shared-account problem

A shared SAP account is one that is used by more than one human person. The contract requires that named users be assigned to specific individuals and that the licence be sufficient for the highest-rights individual who uses the account. In practice estates accumulate shared accounts through several routes: legacy generic IDs that pre-date single-sign-on, manager accounts shared with assistants, contractor accounts passed between successive contractors, training accounts used by multiple trainees, and shop-floor accounts shared across shift workers. The financial and audit-defence consequences are material. This article walks through detection, remediation, and the prevention pattern that stops the issue recurring. It is one of the working patterns underneath our licence optimisation service.

Why SAP cares

The contractual position is straightforward: SAP licences are named-user licences, and a named user is a specific individual. An account used by multiple individuals is a contractual breach. SAP's auditor, on identifying the pattern, treats each additional user of the shared account as an unlicensed user, and the audit finding is the cost of the missing licences. The pattern compounds with classification: a shared account classified as Professional, used by five individuals, generates a finding equivalent to five Professional licences against the one contract licence in place.

SAP does not need to identify the individuals by name to make the finding. The auditor needs to demonstrate that the account is being used by multiple individuals, which is typically inferred from the logon-pattern data (multiple concurrent sessions, geographic anomalies, after-hours patterns inconsistent with a single user). The named-user topic page covers the contractual frame.

The detection patterns

Detection relies on data that already exists in the estate. Six patterns surface most shared accounts.

Concurrent-session detection

Pull the session table and look for accounts with multiple concurrent sessions from different terminals. A single human cannot be in two terminals simultaneously. Accounts with persistent concurrent sessions are shared. The exclusion is legitimate technical accounts (RFC users, batch users) which are properly classified as Communication or Technical users; the detection should run only against named-user classifications.

Geographic-anomaly detection

For estates with VPN logging or workstation-IP capture, accounts that log in from geographically disparate locations within a working day are shared. The customary technical exclusion is travelling users, but the data signature differs: a travelling user shows one location per day, transitioning over time; a shared account shows multiple locations on the same day persistently.

Logon-pattern density

Single users have a recognisable logon-pattern density: a peak during their working hours, a fall outside those hours, weekends quieter than weekdays. Shared accounts have a flatter density, often with logons across multiple time bands. The pattern is a strong indicator even without identity data.

Password-reset frequency

Accounts that have their passwords reset frequently are typically shared. The reset cause is that the prior holder of the account either left and the password was handed over, or shared the password to a new user. The pattern is visible in the authentication log.

Helpdesk-ticket correlation

Tickets that reference the account by user-ID rather than by individual name are evidence of sharing. Helpdesk processes that document the account holder reveal where the documented holder differs across tickets.

Workstation-fingerprint detection

Where workstation fingerprints are available (terminal IDs, MAC addresses), the same account from multiple workstation fingerprints is suggestive. The exclusion is users with multiple devices; the inclusion is repeated overlap with other accounts on the same workstation. The dormant-user cleanup article covers the broader data-discipline pattern.

The remediation sequence

Remediation has three stages. First, identify the individuals behind each shared account. This is intelligence work involving HR, the business unit, and the helpdesk. Second, provision individual accounts for each identified user, with the correct authorisation set. Third, retire or repurpose the shared account: typically converting it to a Technical or Communication user for the integration or batch purpose it actually serves, or deleting it if no legitimate purpose remains.

The sequence is important. Provisioning the individual accounts before retiring the shared one preserves operational continuity. Retiring the shared one before provisioning interrupts operations and creates pressure to recreate the shared account. The transition window should be planned and the retirement deferred until the individual accounts are demonstrated in use.

The shop-floor exception

Shop-floor environments — warehouses, manufacturing lines, retail point-of-sale — have a structural pattern of shared workstations where multiple shift workers use the same terminal. The legitimate solution is not a shared account but a Kiosk-class user or a defined Shop-Floor licence pattern where the contract supports one. Where the contract does not support a Kiosk pattern, individual accounts with shared workstations are the compliant solution; the workstation is shared but the account is not. The named-user blog pillar covers the Kiosk classification.

The prevention controls

Detection and remediation address the existing population. Prevention addresses the recurrence. The standard prevention controls include: a named-user provisioning policy that requires individual accounts for individual users; a shared-account approval workflow that requires named justification, classification as Technical or Communication, and documented review; an automated monitoring rule that flags accounts with concurrent sessions or geographic anomalies; and an annual recertification of any account that holds a named-user classification but shows shared-account patterns. The licence optimisation framework white paper sets out the full control set.

The audit-defence position

Where shared accounts have existed and been remediated before an audit, the audit-defence position is to document the remediation: the detection methodology, the remediation date, the individual accounts provisioned, the shared accounts retired. The auditor's customary challenge is that the remediation is performative rather than substantive; the documentation rebuts the challenge. The insurer case file documents the pattern in practice.

Where to start

Start with the concurrent-session query against the user-master and session tables. The query is a one-day exercise and surfaces the cleanest shared-account candidates. Build the broader detection programme from there.