SAP ships a small set of standard accounts whose initial passwords are published in SAP's own documentation, and because the user master table is client-dependent, those passwords survive in any client where nobody changed them, whatever was done in the client everybody uses.
These are the accounts a password strength test in the RedRays Security Platform finds first, and they are the reason the test is scoped per client rather than per system. This page does not reprint any default password value; the point is where they survive and why.
| Account | What it is for | Where it usually survives |
|---|---|---|
SAP* |
The built-in superuser, present in every client | Old clients, sandbox systems, and any client created by a copy |
DDIC |
The ABAP Dictionary and upgrade account | Systems where the upgrade was done years ago and the password was never rotated |
EARLYWATCH |
The remote service account for SAP support diagnostics | Client 066 on older landscapes, which is often the client nobody thinks about |
TMSADM |
The transport management system account, used by the transport tools | Landscapes where the transport domain was set up once and left alone |
SAPCPIC |
The legacy account for CPI-C and older RFC connections | Systems that carried forward configuration from an older release |
Two behaviours make SAP* a special case worth knowing. It exists in every client, so securing it in one client secures nothing in the others. And if its user master row is deleted, SAP can fall back to a built-in emergency logon with a hardcoded password unless the relevant instance parameter forbids it, which is why deleting the account is not a way of removing the risk. Whether that parameter is set is a profile parameter question.
Because the hardening happens where people are watching. A production client with users in it gets a policy, a review and an owner. Client 000, an old training client, a decommissioned-in-name-only sandbox, or the client that came along with a system copy get none of those, and they hold the same standard accounts with the same documented passwords.
Two ordinary events keep the population alive:
Reset it, in every client, and check what breaks before you do rather than after. Several of these accounts are used by machinery rather than by people. A transport account or a legacy connection account has its password written into a configuration somewhere, so a reset that is correct from a security point of view can stop transports moving or an interface running. The order that works is: find where the credential is embedded, change it in both places, then verify.
The related controls are worth doing in the same pass: lock or expire the accounts that should not be usable, restrict them to the client that needs them, and give the emergency superuser a monitored, alerting path rather than a standing password. What a recovered account could then reach is an authorisation question, which is segregation of duties.
It can tell you that the stored hash for a named account in a named client fell to a candidate password. It cannot tell you whether that account is locked, expired, or of a type that takes no dialog logon, because those fields are not read: see what one password test result says. So a hit on a standard account is a prompt to look at the account, not a finished triage.
It also cannot tell you the account is unused. An account nobody has logged on to interactively may still be the identity behind a background job or a remote function call, and the fastest way to find out is to check where the credential is configured before changing it.
The capability overview is SAP password strength testing, and the three states a result can be in are set out in recovered, resisted, never tested.
No. They are published by SAP and repeated in every hardening guide. The only thing that separates a landscape where they still work from one where they do not is whether somebody changed them in every client and kept them changed.
For one client it is close to it. The work is doing it in every client of every system, including the ones nobody remembers, and doing it again after the next copy. That is what makes it a scanning problem rather than a checklist item.
It helps, and it is not the whole answer. A locked account with a known password is one administrative act away from being usable, and in some configurations the emergency superuser path exists whether or not the account row does.
They belong in the same pass. Accounts created by an implementation partner with a standard password across a whole rollout behave exactly like SAP defaults, and a dictionary attack with a custom seed is the way to test that theory. See what one password test result says.