WebOTG-SM-005 — Default Accounts and Credentials

01 / OBJECTIVE

Objective

What are we verifying?

Verify that vendor-supplied, default or deployment-created accounts cannot be accessed using known or unchanged credentials and that unnecessary privileged accounts are disabled or removed.

Applications, frameworks, appliances, administration consoles and supporting services may be deployed with predefined accounts. If these accounts remain active with known credentials, an attacker may gain access without exploiting a software vulnerability.

The assessment should therefore consider both the existence of default accounts and the authentication controls governing those accounts.

Never test credentials outside authorization

Credential testing must be explicitly authorized. Do not attempt authentication against third-party systems or accounts merely because credentials are publicly documented.

02 / SCOPE

Scope

Review default or deployment-created accounts across application and supporting administrative surfaces, including where applicable:

Web application administrative accounts

CMS administrator accounts

Framework administration interfaces

Application deployment accounts

Supporting management interfaces

Service accounts exposed through application interfaces

Default users created during installation

Accounts inherited from deployment templates

03 / PREREQUISITES

Prerequisites

Authorization	Obtain explicit authorization to test authentication controls.
Account inventory	Obtain an authorized inventory of application and administrative accounts.
Deployment documentation	Identify accounts created by installation, templates or deployment procedures.
Vendor documentation	Review official documentation for default account behavior.
Test credentials	Use only credentials explicitly supplied or authorized for security testing.

04 / METHODOLOGY

Methodology

The assessment should begin with documentation and configuration review before performing controlled authentication testing.

Method	Purpose
Account inventory	Identify active, disabled and privileged accounts.
Documentation review	Identify vendor-supplied or installation credentials.
Configuration review	Determine whether default accounts remain enabled.
Controlled authentication	Verify whether authorized default credentials remain accepted.

05 / PROCEDURE

Test procedure

01

Identify authentication surfaces Identify normal login pages, administrative interfaces and other authorized authentication endpoints.

02

Obtain account inventory Review authorized application and deployment records for predefined or installation-created accounts.

03

Review default account state Determine whether identified accounts are enabled, disabled, renamed, removed or otherwise controlled.

04

Review credential requirements Confirm whether default credentials must be changed during installation or first use.

05

Perform controlled authentication Where explicitly authorized, verify that known default credentials are rejected or that a mandatory credential change is enforced.

06

Review privilege level Determine whether any remaining default account has unnecessary administrative privileges.

06 / ACCOUNT DISCOVERY

Account discovery

Sources of account information

Source	Review
Deployment documentation	Identify accounts automatically created during installation.
Application administration	Review current users, roles and account status.
Configuration	Identify predefined usernames and account initialization settings.
Vendor documentation	Determine whether documented default accounts or first-use credentials exist.
Deployment automation	Review templates, scripts and provisioning processes for hard-coded initial accounts.

Example authentication response

Illustrative response EXAMPLE

HTTP/1.1 401 Unauthorized
Content-Type: application/json

{
    "error": "invalid credentials"
}

The response above is only an illustration of an authentication failure. A security assessment must consider the complete authentication flow and must not rely solely on status codes.

07 / ASSESSMENT

Assessment

Determine whether an account is genuinely a default account and whether its current state creates security exposure.

Condition	Assessment
Default account removed	Generally acceptable if no operational requirement exists for the account.
Default account disabled	Generally preferable to leaving an unnecessary account active.
Default account active with unique credentials	Assess whether the account remains necessary and appropriately privileged.
Default credentials accepted	Security weakness requiring remediation.
Mandatory password change enforced	Determine whether the original default credential can actually be reused.
Default privileged account exposed	Higher-risk condition requiring immediate security review.

Privilege matters

A default account with administrative privileges presents substantially greater risk than an intentionally retained low-privilege service account. Severity must be based on the actual impact.

08 / EXPECTED RESULT

Expected result

Pass condition

Default credentials cannot be used to authenticate to the application or supporting management interface, unnecessary default accounts are removed or disabled, and retained accounts use unique, controlled credentials with only required privileges.

Where a vendor requires a predefined account for normal operation, the account should be explicitly documented, securely configured and subject to appropriate access controls.

09 / FAILURE CRITERIA

Failure criteria

Known default credentials are accepted by an authorized authentication interface.

A vendor-supplied administrative account remains enabled without an operational requirement.

Default credentials are not required to be changed during deployment or first use.

A retained default account has excessive privileges.

Deployment automation recreates default credentials after remediation.

Administrative default accounts are exposed through an externally accessible management interface without adequate access restrictions.

Example finding HIGH RISK

An administrative account created during application installation remains active and accepts its vendor-documented initial credential. The account provides privileged access to the application's management interface.

10 / REMEDIATION

Remediation

Default credentials should never remain usable in a production deployment. Default accounts that are not required should be removed or disabled.

Recommended approach

Inventory all application and administrative accounts.
Identify accounts created by installation or deployment templates.
Remove unnecessary default accounts.
Disable accounts that cannot be removed but are not required for normal operation.
Force replacement of vendor-supplied credentials during initial configuration.
Assign unique credentials to required accounts.
Apply least privilege to retained accounts.
Prevent deployment automation from restoring default credentials.
Restrict management interfaces to authorized networks where possible.
Record the resulting account state in deployment documentation.

Example deployment policy

Illustrative policy EXAMPLE

default_admin:
    enabled: false

initial_credentials:
    rotation_required: true

administrative_access:
    least_privilege: true

The example represents a conceptual deployment policy, not a vendor-specific configuration format.

11 / VERIFICATION

Verification

01

Confirm account state Verify that unnecessary default accounts are removed or disabled.

02

Repeat authorized credential testing Where permitted, confirm that previously accepted default credentials are rejected.

03

Verify password-change enforcement If the account is retained, confirm that initial credentials must be replaced before normal use.

04

Verify privilege reduction Confirm that retained accounts have only the privileges required for their intended purpose.

05

Verify deployment persistence Confirm that application updates, rebuilds or automated deployments do not restore default credentials or accounts.

PASS

Default credentials are unusable and unnecessary default accounts are appropriately controlled.

FAIL

Default credentials or uncontrolled default accounts remain exploitable.

NOT TESTED

Required account or authentication verification could not be completed.

12 / EVIDENCE

Evidence requirements

Application and environment tested

Authentication interface tested

Account identification source

Account status before remediation

Authorized authentication result

Remediation evidence

Post-remediation authentication result

Final account and privilege state

Never include credentials in published evidence

Do not record or publish passwords, access tokens, session identifiers, recovery codes or other authentication secrets. Evidence should demonstrate the result without exposing the credential itself.

13 / CLASSIFICATION

Classification

WebOTG procedure	WebOTG-SM-005
OWASP category	A02:2025 — Security Misconfiguration
Procedure type	Default account and credential review
Assessment result	PASS / FAIL / NOT TESTED
Finding severity	Determine from privilege level, accessibility, authentication impact, affected resources and resulting business impact.

WebOTG classification notice

WebOTG-SM-005 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	Authentication and configuration testing methodology.
OWASP ASVS	Application authentication and access-control verification requirements.
Vendor security documentation	Identification and secure handling of vendor-supplied accounts and credentials.

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