Shared and Generic Accounts Governance Guide

Shared and generic accounts sit between human and non-human identity policy, so in most organisations neither policy is applied to them and nobody can say who used them last. Shared mailboxes, kiosk and shift logins, built-in administrator and root accounts, vendor support accounts, training and demo logins and the "ops@" account that five engineers know the password for all break the basic promise of identity governance: one account, one accountable person. This guide shows how to classify them, which ones to eliminate, how to control the ones you must keep, and how to measure progress. It is for IAM, IGA and PAM teams and for auditors who keep finding the same generic accounts in every review. Where a human is using a machine identity, the OWASP NHI Top 10 NHI10 Human Use of NHI Guide covers that specific risk; this guide covers the wider family.

Key takeaways

Classify before you control. A shared mailbox, a kiosk login, a built-in admin and a team password are different problems with different fixes; one generic "shared account policy" fails all of them.
Individual authentication first, shared account second. NIST SP 800-53 IA-2(5) requires users to be individually authenticated before they are granted access to shared accounts or resources; that single rule removes most of the risk.
Most shared accounts can be replaced. Delegated mailbox permissions, shared device modes, role-based access and PAM check-out cover the large majority of cases where a shared password is used today.
The ones you keep must be owned and brokered. Each surviving shared account needs a named owner, a documented justification, a vaulted credential that rotates after use, and logs that tie each session to a person.
Sign-in to a non-interactive shared object is itself an alert. Microsoft's guidance is to block sign-in for every shared mailbox account and keep it blocked; any interactive sign-in to such an account signals misuse or compromise.

What counts as a shared or generic account

A shared account is any account whose credential is known to, or used by, more than one person. A generic account is any account not tied to a single named person or a single defined workload. They overlap: a generic account becomes shared the moment its password is written in a team wiki.

Category	Examples	Why it exists	Default treatment
Shared resource objects	Shared mailboxes, shared calendars, team drives, resource accounts for rooms	Teams need a common inbox or resource	Keep the object, block direct sign-in, grant access through membership
Shift and kiosk logins	Store tills, nurse stations, warehouse scanners, reception PCs	Fast handover between workers	Replace with shared device mode, kiosk mode or fast individual sign-in
Built-in and default privileged accounts	Windows built-in Administrator, root, enable on network devices, database sa, appliance admin	Shipped by the vendor; needed for recovery	Keep, vault, rotate, restrict to break-glass or PAM check-out
Team administrative accounts	"netadmin", "dba", "ops" accounts used by a whole team	Convenience, licensing, legacy tools without RBAC	Replace with named admin accounts; broker any that remain
Vendor and support accounts	"vendor_support", supplier logins in OT and line-of-business apps	Third-party maintenance	Named vendor users or brokered, time-bound access. See the Vendor Privileged Access Management Guide
Training, test and demo accounts	"training01" to "training20", "demo", "test"	Courses, testing, sales demos	Time-bound, environment-restricted, auto-expiring
Human use of machine accounts	People signing in with a service account password	Workarounds when access is slow	Eliminate; covered by NHI10

The last row matters for classification: a service account used only by a workload is an NHI and belongs in the Service Account Security Guide scope. The moment a person signs in with it, it is also a shared account and both sets of controls apply.

Why these accounts are high risk

No attribution: logs show the account, not the person. Investigations, segregation of duties and non-repudiation all fail.
No lifecycle trigger: leavers processes remove the person's own accounts but do not change the shared password they still know. The joiner-mover-leaver process has no event for "remove from the people who know the ops password". See the Joiner-Mover-Leaver Guide.
Weak authentication: MFA is often skipped because a second factor cannot be shared conveniently, so a phished or leaked password is enough (ATT&CK T1078 Valid Accounts, with T1078.001 Default Accounts for vendor defaults and T1078.003 Local Accounts).
Credential sprawl: the password ends up in spreadsheets, chat channels and browser profiles. CISA and NSA's joint advisory on the top ten cybersecurity misconfigurations (AA23-278A) lists cleartext passwords in files such as spreadsheets as a recurring finding (T1552.001 Credentials In Files).
Excess privilege: shared accounts accumulate the union of everything every user needed. The same advisory names default credentials and privileged domain accounts loaded on printers and scanners as common weaknesses.
Undetectable sharing: NIST SP 800-63B observes that very few technical controls can detect or prevent willful sharing of credentials, so policy alone does not remove the practice.

Replacing shared accounts with individual access

The first goal is elimination. For each category, there is usually a pattern that gives the business what it needs with individual identities.

Shared pattern	Replacement	Specifics
Team signs in to a shared mailbox with its password	Delegated access through membership	Microsoft states that a shared mailbox is not intended for direct sign-in, that its user account has a system-generated password nobody should use, and that sign-in for the account should always be blocked. Grant Full Access, Send As or Send on Behalf to individuals or a group.
Shift workers share one tablet login	Shared device mode	Microsoft Entra shared device mode on iOS, iPadOS and Android lets each worker sign in once to all supported apps and sign out of all of them at shift end. See the Passwordless for Frontline and Shared Devices Guide.
Public or single-purpose terminal	Kiosk mode with no privileged rights	Windows Assigned Access runs a single app (kiosk) or a restricted set of apps; the account behind it has no access beyond that app. See the Kiosk and Shared Device Security Guide.
Team admin account for servers or network devices	Named admin accounts with RBAC, or PAM-brokered sessions	Each admin gets a dedicated admin account; devices authenticate through RADIUS or TACACS+ against the directory so logs show the person.
Team knows the application admin password	SSO with an admin role group	Federate the application and map an IdP group to the admin role; local admin kept only as break-glass.
Generic training logins	Just-in-time training identities	Create named or numbered accounts per cohort that expire automatically at course end, in a non-production tenant.

Decision rule: if the application supports more than one user and any form of role, a shared account is a choice, not a constraint. Treat it as an exception requiring sign-off.

Controlling the shared accounts you must keep

Some accounts cannot be removed: built-in administrator and root accounts, appliance and OT device logins with a single admin user, emergency access accounts, and applications with no user model. NIST SP 800-53 AC-2(9) lets organisations permit shared and group accounts only where they meet defined conditions; PCI DSS v4.0 Requirement 8.2.2 similarly allows group, shared or generic IDs only by exception, with business justification, management approval, limited duration, individual identity confirmed before access and every action attributable to an individual. A workable set of conditions:

Register it: record the account, system, category, business justification, approver, named owner and the list of people allowed to use it. See the NHI Ownership Guide for ownership models.
Vault the credential: store it in a PAM vault or enterprise password manager, never in a spreadsheet or chat. Users retrieve it only after authenticating as themselves with MFA, which is how IA-2(5) is met in practice.
Prefer brokering to disclosure: where the PAM tool can inject the credential into a session, users never see the password. Record the session.
Rotate after each use: check-in triggers rotation, so knowledge of the password expires with the session. NIST SP 800-63B no longer requires periodic password changes for individual users, but a password that several people have seen should be treated as exposed and changed.
Restrict where it works: limit logon to specific hosts, networks or the PAM proxy, and deny interactive logon where only console recovery is needed.
Time-bound access: grant the right to check out for hours, not permanently, and expire training, vendor and project accounts automatically.
Review it: include the register in each access review cycle; the owner certifies both the account and its list of permitted users.

Built-in and default accounts

Windows built-in Administrator: unique, rotated password per device with Windows LAPS; disable where not needed. See the Local Administrator Password Solution (LAPS) Guide.
Unix and Linux root: disable direct root login over SSH, use sudo with named accounts, vault the root password for console recovery. See the Unix and Linux Privileged Access Guide.
Network, OT and appliance defaults: change vendor defaults before connection, then vault; where the device supports external authentication, use it.
Emergency access: handle as break-glass with alerts on every use. See the Break-Glass Account Guide.

Implementation roadmap

Discover (month 1): search directories and key applications for accounts with no employee ID or manager, names matching generic patterns (admin, test, temp, training, shared, support, ops, team names, role mailboxes), and accounts with sign-ins from several devices or locations at once. Scan wikis, file shares and chat for password lists.
Classify (month 1 to 2): assign each account a category from the table above and an interim owner, usually the manager of the team that uses it.
Quick wins (month 2): block sign-in on every shared mailbox and resource account, disable training and test accounts not used in 90 days, change vendor default passwords.
Replace (months 2 to 9): migrate shift logins to shared device mode or kiosk mode, team admin accounts to named admins, and application shared logins to SSO groups. Pilot one site or team at a time and keep the old account disabled, not deleted, for 30 days as a rollback.
Broker what remains (months 3 to 9): onboard surviving accounts to PAM with check-out, rotation and session recording. See the Privileged Account Discovery and Onboarding Guide.
Prevent recurrence: require an exception and owner for any new generic account; block account creation without an owner attribute in provisioning workflows.

Small organisations can often skip PAM for a handful of accounts: a business password manager with individual sign-in, per-account access logging and a rotation rule after staff changes gives most of the benefit. Large organisations should make the shared account register part of the IGA platform so that certification, owner transfer on leaver events and expiry are automatic.

Detection and measurement

Interactive sign-ins to blocked objects: any successful sign-in by a shared mailbox or resource account in the identity provider sign-in logs.
Mailbox delegate activity: Microsoft Purview mailbox auditing is on by default, includes shared mailboxes and records delegate actions such as SendAs, SendOnBehalf, MailItemsAccessed and UpdateInboxRules. New inbox rules on a shared mailbox are a common sign of misuse.
Concurrent use: the same account signed in from two hosts or locations at once, or Windows Event ID 4624 for a generic account on hosts outside its permitted set.
Use without check-out: any logon by a vaulted shared account that does not match a PAM check-out record means someone has kept the password.
Dormancy: shared accounts with no use in 90 days should be disabled; any later use of a disabled or dormant account should alert.

Metric	Target
Shared and generic accounts with a named owner and justification	100%
Shared mailbox and resource accounts with sign-in blocked	100%
Surviving privileged shared accounts vaulted with rotation after use	100%
Logons by vaulted shared accounts without a matching check-out	Zero
Count of shared accounts, quarter on quarter	Falling
Shared credentials found in files and chat by scanning	Zero open findings older than 14 days

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	AC-2(9) Restrictions on Use of Shared and Group Accounts	Only permit shared accounts that meet defined conditions
NIST SP 800-53 Rev 5	IA-2(5) Individual Authentication with Group Authentication	Authenticate the person before granting the shared account
NIST SP 800-53 Rev 5	AC-2, AC-6(5), IA-5, AU-12	Account management, privileged accounts, credential management, logging
NIST CSF 2.0	PR.AA-01, PR.AA-05	Identity and credential management, access permissions
CIS Controls v8.1	5.1 Inventory of Accounts; 5.3 Disable Dormant Accounts; 5.4 Dedicated Administrator Accounts	Inventory, dormancy and admin separation
ISO/IEC 27001:2022 Annex A	A.5.16 Identity management; A.5.17 Authentication information; A.8.2 Privileged access rights	Identity, credential and privileged access policy
PCI DSS v4.0	Requirement 8.2.2	Shared and generic IDs by exception with individual attribution
MITRE ATT&CK v20	T1078.001, T1078.003, T1552.001	Default and local account abuse, credentials in files

Common failure patterns

Policy without inventory: a "no shared accounts" policy is published but nobody searched for them, so the auditor finds the same accounts next year.
Vaulted but still known: the password is put in a vault but never rotated, so everyone who knew it still does.
MFA exemptions: shared accounts are excluded from Conditional Access or MFA policies "because the team cannot share a phone", leaving the weakest accounts with the weakest protection.
Shared mailbox sign-in left on: someone sets a password on the mailbox account so a team can use it from a phone; it becomes an unmonitored, password-only account.
Ownerless accounts that nobody disables: generic accounts survive reorganisations because no leaver event ever applies to them.
Personal storage of shared credentials: team passwords saved in personal browser profiles or password managers outside company control.

Lessons from incidents

Ownerless access outlives its purpose: in the Colonial Pipeline ransomware attack, a legacy VPN profile that was no longer in use had never been disabled, had no MFA, and its password appeared in a leaked credential set. Accounts without a lifecycle owner, which describes most generic accounts, fail in exactly this way.
Credentials follow people to uncontrolled places: in the Okta support system breach, a service account's credentials were saved to an employee's personal Google profile. A credential that several people use is far more likely to end up somewhere like this.

Practitioner checklist

Discover and classify every shared and generic account by category, with an interim owner.
Block direct sign-in on every shared mailbox and resource account and alert on any sign-in.
Replace shift and kiosk logins with shared device mode or kiosk configurations.
Replace team admin accounts with named admin accounts and RBAC.
Vault every remaining privileged shared account, require individual MFA before check-out, rotate after use.
Change vendor defaults and manage built-in administrator passwords with LAPS or PAM.
Expire training, test and vendor accounts automatically.
Scan wikis, shares and chat for shared passwords and rotate what you find.
Certify the shared account register in every access review cycle.

Shared and Generic Accounts Governance Guide: classifying, controlling and retiring accounts nobody owns