WebOTG-SM-008 — Default Accounts and Credentials

01 / OBJECTIVE

Objective

What are we verifying?

Verify that default, vendor-supplied, unnecessary or unchanged accounts cannot be used to obtain unauthorized access to the application or its supporting administrative interfaces.

Applications and infrastructure components may be deployed with predefined accounts or credentials. Leaving such accounts enabled without a documented security requirement increases the risk of unauthorized access.

The review should cover both the web application's own accounts and externally managed components that can materially affect the security of the application.

Do not perform uncontrolled credential guessing

Use authorized test credentials and documented vendor defaults where permitted by the assessment scope. Avoid password spraying or high-volume authentication attempts that could lock accounts or affect production availability.

02 / SCOPE

Scope

Review accounts and authentication surfaces including:

Application administrator accounts

Initial setup accounts

Vendor or framework accounts

CMS and management interfaces

Monitoring and diagnostic interfaces

Database administration interfaces

Infrastructure management interfaces

Service accounts used by the application

03 / PREREQUISITES

Prerequisites

Authorization	Confirm explicit authorization to assess authentication and administrative interfaces.
Account inventory	Obtain an authorized inventory of application, administrative and service accounts.
Deployment documentation	Identify vendor-provided accounts and credentials expected during initial setup.
Test credentials	Use dedicated test accounts wherever authentication behavior must be verified.

04 / METHODOLOGY

Methodology

Combine configuration review, account inventory analysis and controlled authentication testing. The objective is to establish whether unnecessary or default access paths remain available.

Method	Purpose
Account inventory review	Identify predefined, privileged, dormant and service accounts.
Configuration review	Determine whether vendor or deployment defaults remain enabled.
Controlled authentication test	Verify whether authorized default or test credentials provide access.
Privilege review	Determine whether unnecessary accounts have elevated privileges.

05 / PROCEDURE

Test procedure

01

Build the account inventory Identify administrative, standard, service, setup and vendor-provided accounts relevant to the application.

02

Identify predefined accounts Review deployment documentation and authorized configuration sources for accounts created by the application or its components.

03

Determine account necessity Establish whether each account is required for current business or technical operations.

04

Review credential state Verify that initial or vendor-provided credentials have been replaced or otherwise secured.

05

Perform controlled authentication Where authorized, use dedicated test accounts or documented vendor defaults to verify whether prohibited access remains possible.

06

Review privileges Determine whether default or unnecessary accounts possess administrative or other excessive privileges.

06 / ACCOUNT TYPES

Account review categories

Account type	Review requirement
Default administrator	Confirm that vendor or initial setup credentials are no longer usable.
Default user	Determine whether the account is required and whether its credentials were changed.
Service account	Verify that it has a defined purpose, minimum privileges and appropriate credential management.
Dormant account	Disable or remove accounts that are no longer required.
Emergency account	Verify that use is controlled, monitored and justified.
Vendor support account	Confirm that access is disabled unless explicitly required and controlled.

Example configuration review

Illustrative account inventory EXAMPLE

Account              Role             Status
------------------------------------------------
application-admin    Administrator    Required
initial-setup        Administrator    Review
demo-user            Standard         Disabled
vendor-support       Support          Disabled
report-service       Service          Required

The example demonstrates the type of inventory that can be maintained during an assessment. Actual account names and privileges should never be published if they could assist unauthorized access.

07 / ASSESSMENT

Assessment

Condition	Assessment consideration
Default account disabled	Generally appropriate where the account is not required.
Default credentials replaced	Verify that the original credentials cannot still be used.
Default account remains required	Review whether it has strong credentials, appropriate restrictions and minimum privileges.
Unnecessary privileged account enabled	Treat as a configuration weakness and determine its practical security impact.
Default credentials provide access	Treat as a security finding. Assess privileges and reachable functionality.

08 / EXPECTED RESULT

Expected result

Pass condition

Default and unnecessary accounts are disabled or removed, required accounts use appropriately managed credentials, and no unauthorized access is available through vendor-supplied or unchanged credentials.

Privileged access should be limited to accounts with a documented operational requirement and should follow least-privilege principles.

09 / FAILURE CRITERIA

Failure criteria

Vendor-supplied default credentials remain valid.

An unnecessary default account remains enabled.

A default account has unnecessary administrative privileges.

Dormant or obsolete privileged accounts remain active.

Vendor support accounts remain accessible without a documented operational requirement.

Initial setup credentials can still be used after deployment.

Example finding AUTHENTICATION RISK

An administrative account created during initial application deployment remains enabled and retains elevated privileges after production deployment. The account is not required for current operations and has not been adequately restricted.

10 / REMEDIATION

Remediation

Remove unnecessary accounts and ensure that every remaining account has a defined purpose, controlled credentials and appropriate privileges.

Recommended approach

Inventory all application and administrative accounts.
Identify vendor-supplied and initial deployment accounts.
Disable or remove accounts that are not required.
Replace default credentials for accounts that must remain.
Apply least-privilege permissions.
Restrict administrative access to authorized users.
Establish controlled procedures for emergency accounts.
Review vendor support accounts and disable them when support access is not required.
Monitor privileged authentication activity.
Include account review in deployment and configuration management processes.

Example account policy

Illustrative policy EXAMPLE

Default accounts:
    Disable unless operationally required.

Initial credentials:
    Replace before production deployment.

Privileged accounts:
    Assign only where required.

Service accounts:
    Use dedicated credentials and minimum privileges.

Vendor support:
    Disable by default.

Dormant accounts:
    Disable or remove according to policy.

Do not disable accounts without dependency analysis

Some service or system accounts may be required for application operation. Confirm dependencies before disabling an account and document any approved exception.

11 / VERIFICATION

Verification

01

Repeat the account inventory review Confirm that unnecessary and default accounts have been disabled or removed.

02

Re-test controlled authentication Where authorized, confirm that previously identified default credentials no longer provide access.

03

Verify required accounts Confirm that legitimate service and administrative accounts continue to operate correctly.

04

Verify privileges Confirm that remaining accounts have only the privileges required for their documented purpose.

05

Verify persistence Confirm that disabled accounts remain disabled after application restart, deployment or configuration reload.

PASS

Default and unnecessary access paths are removed or appropriately secured.

FAIL

Default credentials or unnecessary privileged accounts remain usable.

NOT TESTED

Account configuration or authentication behavior could not be adequately verified.

12 / EVIDENCE

Evidence requirements

Application and environment tested

Authorized account inventory

Default-account configuration evidence

Authentication test result

Privilege assessment

Remediation evidence

Post-remediation authentication result

Final PASS / FAIL determination

Never publish credentials

Evidence must never contain passwords, password hashes where disclosure creates risk, API keys, session tokens, private keys or other authentication secrets. Sanitize screenshots and configuration exports before publication.

13 / CLASSIFICATION

Classification

WebOTG procedure	WebOTG-SM-008
OWASP category	A02:2025 — Security Misconfiguration
Procedure type	Default account and credential review
Assessment result	PASS / FAIL / NOT TESTED
Finding severity	Determine from account privileges, accessibility, exploitability and resulting security impact.

WebOTG classification notice

WebOTG-SM-008 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 secure configuration.
Vendor security documentation	Default accounts, initial credentials and secure deployment requirements.
Organizational access-control policy	Account lifecycle, privileged access and least-privilege requirements.

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.