WebOTG Security Testing Library ● Public reference
W WebOTG
Search
WebOTG
Standards Countries Topics Resources About
WEBOTG SECURITY TESTING PROCEDURE

WebOTG-SM-012 — Default or Unnecessary Accounts

A structured procedure for identifying default, vendor-supplied, dormant or otherwise unnecessary application accounts and verifying that privileged identities are appropriately controlled throughout their lifecycle.

WebOTG ID SM-012 OWASP A02:2025 Type Account Configuration Method Account Inventory & Access Review Version 1.0
01 / OBJECTIVE

Objective

What are we verifying?

Verify that default, vendor-supplied, dormant and unnecessary application accounts cannot provide unauthorized access or unnecessary privileges.

Applications and supporting components frequently introduce accounts during installation, deployment or initial configuration. These accounts may be intended for setup, maintenance, demonstration or vendor support.

Leaving such accounts enabled after deployment can unnecessarily increase the application's attack surface. Particular attention should be given to accounts that retain predictable credentials, excessive privileges or access that is no longer required.

Account existence alone is not a finding

A system account may be required for legitimate application operation. The assessment should establish whether an account is necessary, what it can access, how it authenticates and whether its privileges are appropriate.

02 / SCOPE

Scope

Review accounts associated with:

Application administrators
Initial installation or setup accounts
Vendor-supplied accounts
Demonstration or sample accounts
Dormant administrative accounts
Service accounts
Emergency or break-glass accounts
Test and development accounts accidentally deployed to production
03 / PREREQUISITES

Prerequisites

Authorization Confirm authorization to review account configuration and perform permitted authentication tests.
Account inventory Obtain an authoritative inventory of application and administrative accounts.
Role information Obtain the expected role and privilege associated with each relevant account.
Deployment documentation Identify vendor-created, installation, service and emergency accounts.
Test credentials Use dedicated authorized test accounts. Never test using production credentials unless explicitly required and authorized.
04 / METHODOLOGY

Methodology

Establish the expected account population first. Compare the actual deployed accounts against that baseline, then assess the necessity, authentication controls and privileges associated with each account.

Method Purpose
Account inventory review Identify accounts currently configured within the application.
Configuration review Determine account purpose, status and assigned privileges.
Authentication testing Verify permitted authentication behavior using authorized test credentials.
Authorization testing Verify that account privileges match the documented role.
Lifecycle review Determine whether unnecessary accounts are disabled, removed or otherwise appropriately controlled.
05 / PROCEDURE

Test procedure

01
Obtain the account inventory Identify all application accounts relevant to the assessment, including administrative, service and vendor-created identities.
02
Determine account ownership Establish the responsible person, team, service or component associated with each account.
03
Determine account necessity Verify that each enabled account has a current operational or security requirement.
04
Review account status Identify disabled, dormant, expired and unnecessary accounts.
05
Review privileges Confirm that each account has only the permissions required for its intended purpose.
06
Review authentication controls Verify that authentication requirements are appropriate for the account's privilege level and operational role.
07
Verify unnecessary accounts cannot authenticate Where authorized, confirm that disabled or decommissioned accounts cannot be used to access the application.
06 / ACCOUNT TYPES

Account categories

Account type Review objective
Default account Determine whether the account is required and whether its initial credentials or configuration remain active.
Vendor account Verify that vendor access is required, controlled and attributable.
Sample account Remove or disable accounts that exist only for demonstration or testing.
Dormant account Determine whether continued access is justified and appropriately controlled.
Service account Verify documented ownership, required privileges and appropriate credential management.
Emergency account Verify that exceptional access is strongly controlled and auditable.
Development / test account Confirm that non-production identities have not been unintentionally deployed into production.

Example account baseline

Illustrative account inventory EXAMPLE 
Account              Type          Status       Privilege
-----------------------------------------------------------
admin                Human         Enabled      Administrator
application-worker   Service       Enabled      Application service
vendor-support       Vendor        Disabled     Restricted
demo                  Sample        Disabled     None
test-admin           Test          Disabled     None
break-glass           Emergency     Controlled   Administrator
07 / ASSESSMENT

Assessment

Condition Assessment consideration
Required account Confirm that its purpose, owner and privileges are documented.
Unnecessary account Disable or remove the account according to the organization's lifecycle policy.
Default account Verify that default credentials are not retained and that the account remains necessary.
Dormant account Determine whether the account still requires access.
Excessive privilege Reduce privileges to the minimum required by the account's function.
Unowned account Treat absence of accountable ownership as a lifecycle and governance concern.
08 / EXPECTED RESULT

Expected result

Pass condition

Every enabled account has a documented purpose, accountable ownership, appropriate authentication controls and only the privileges necessary to perform its intended function.

Accounts that are no longer required should be disabled or removed. Default, demonstration and development identities should not remain unnecessarily active in production.

09 / FAILURE CRITERIA

Failure criteria

A default account remains enabled without a documented operational requirement.
A vendor, sample or test account remains active unnecessarily.
An account has privileges exceeding its documented operational requirements.
Dormant accounts remain enabled without justification.
An administrative account has no accountable owner.
Disabled or decommissioned accounts can still authenticate through an alternate access path.
Example finding ACCOUNT CONFIGURATION

A vendor-supplied administrative account remains enabled in the production application despite documentation indicating that vendor access is not required during normal operation. The account has administrative privileges and should be disabled or otherwise placed under controlled access procedures.

10 / REMEDIATION

Remediation

Establish an account lifecycle process that prevents unnecessary identities from remaining active and ensures privileged accounts have clear ownership and appropriate access.

Recommended approach

  1. Inventory all application accounts.
  2. Identify the owner and purpose of each account.
  3. Remove or disable accounts that are not required.
  4. Replace shared administrative identities with individually attributable accounts where practical.
  5. Review and reduce excessive privileges.
  6. Change or invalidate vendor-supplied credentials where those accounts must remain enabled.
  7. Apply appropriate authentication requirements to privileged accounts.
  8. Establish an inactivity and account-review process.
  9. Ensure development and test accounts cannot be unintentionally promoted to production.
  10. Document exceptional accounts such as emergency or break-glass identities.

Example account lifecycle

Illustrative lifecycle EXAMPLE 
Account requested
       |
       v
Business purpose documented
       |
       v
Owner assigned
       |
       v
Least privilege applied
       |
       v
Authentication controls applied
       |
       v
Account enabled
       |
       v
Periodic review
       |
       +---- Required ----> Remain active
       |
       +---- Not required -> Disable / remove
Do not delete service accounts blindly

Removing a service identity without understanding its dependencies can interrupt production services. First establish the account's purpose and dependencies, then migrate or disable it through a controlled change.

11 / VERIFICATION

Verification

01
Reconcile the account inventory Confirm that unnecessary accounts have been disabled or removed from the production system.
02
Verify disabled accounts Using authorized test credentials where available, confirm that disabled accounts cannot authenticate.
03
Verify privileges Confirm that retained accounts have only the privileges required for their documented role.
04
Verify default credentials Where applicable and explicitly authorized, verify that vendor or installation credentials are no longer usable.
05
Verify alternate authentication paths Confirm that an account disabled in one interface cannot still access the application through another supported authentication path.
06
Verify deployment persistence Confirm that account configuration remains correct after redeployment, restoration, configuration synchronization or application restart where applicable.
PASS

Required accounts are controlled appropriately and unnecessary accounts cannot provide access.

FAIL

Unnecessary, default or improperly privileged accounts can provide unauthorized or excessive access.

NOT TESTED

Account configuration or authentication behavior could not be adequately verified.

12 / EVIDENCE

Evidence requirements

Account inventory and account types
Account purpose and ownership
Account status
Assigned privileges
Authentication requirements
Before-remediation account state
Remediation record
Post-remediation account state
Authentication verification result
Final PASS / FAIL determination
Never publish authentication secrets

Evidence must not contain passwords, password hashes, API keys, recovery codes, session tokens or other authentication secrets. Account names should also be redacted when their disclosure creates a security concern.

13 / CLASSIFICATION

Classification

WebOTG procedure WebOTG-SM-012
OWASP category A02:2025 — Security Misconfiguration
Procedure type Account configuration and lifecycle review
Assessment result PASS / FAIL / NOT TESTED
Finding severity Determine from account privilege, accessibility, authentication controls, exposure and resulting impact.
WebOTG classification notice

WebOTG-SM-012 is a WebOTG-defined verification procedure. The identifier is not an OWASP-defined test identifier.

14 / REFERENCES

References

Source Relevance
OWASP Top 10:2025 — A02 Security Misconfiguration category.
OWASP Web Security Testing Guide Web application security testing methodology.
OWASP Application Security Verification Standard Verification requirements related to authentication, authorization and account management.
Application account-management policy Organizational requirements for account creation, ownership, review and removal.
Vendor deployment documentation Identification of installation, service and vendor-supplied accounts.

WebOTG should maintain official source URLs, source versions and review dates through its content-management system so references can be updated independently of the procedure template.