Skip to content
System access
ASD ISMISM-1875

ASD ISM 1875 Monthly system scans to detect credentials stored in the clear

What it says

Systems are scanned at least monthly to identify any credentials that are being stored in the clear.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

Run a scan across your systems at least once a month to find any passwords, keys or other credentials sitting unprotected in plain text, then deal with what is found.

This control requires you to scan your systems at least monthly to find credentials (passwords, API keys, tokens, private keys and similar secrets) that are being stored in the clear, meaning unencrypted and readable by anyone who can open the file, script, database or configuration where they sit. Credentials in the clear accumulate quietly. A developer hard-codes a database password into a script to get something working, a service account password is saved in a spreadsheet, a connection string with an embedded key is left in a configuration file, or a backup copies all of it somewhere else. Nobody intends to leave them there, but once an attacker gains even limited access to a system, these plain-text credentials are exactly what they look for. A single exposed password can turn a minor foothold into full control of a database, an administrative account or a cloud environment. The point of a regular, scheduled scan is that you find these credentials before an attacker does. Making it at least monthly means new leaks are caught within weeks rather than lingering for years, and it gives you an ongoing measure of how well your secure credential-handling practices are actually working.

Why it matters

If systems are not scanned regularly, credentials stored in the clear go unnoticed and remain available to anyone who gains access to the file system, code repository, database or backup that holds them. An attacker who lands on a low-value system can harvest these credentials and move laterally to far more sensitive systems, escalate to administrative privileges, or access cloud services and data stores directly. Because the credentials are legitimate, this activity often blends in with normal use and can persist for a long time before detection. It also undermines other controls, such as multi-factor authentication and privileged access management, when the underlying secrets can simply be read from disk.

How to implement

  1. The security team defines the scan scope by building and maintaining an inventory of systems to be scanned, including servers, workstations, file shares, source code repositories, configuration management stores, databases and backup locations, and reviews it monthly so new systems are added.

  2. The security or platform team selects and configures a credential-discovery tool (for example a secrets scanner for code and file systems, or a vulnerability scanner with plain-text credential checks) with detection patterns for passwords, API keys, tokens, private keys and connection strings, and tunes them to reduce false positives.

  3. The scan owner schedules the scan to run automatically at least once a month through the organisation's scheduler or CI pipeline, and configures alerts so a failed or incomplete run is noticed and re-run rather than silently skipped.

  4. The scan owner reviews each month's results within an agreed timeframe, records confirmed findings in the issue tracker with the system, location and credential type, and assigns each to the responsible system owner for remediation.

  5. System owners remediate confirmed findings by removing the credential from the clear-text location, rotating it because it must be treated as exposed, and relocating it to an approved secure store such as a secrets manager, then the scan owner verifies closure in the following month's scan.

Keep it running

In practice this control runs as a recurring job on the security or platform team's calendar. Someone owns the scan schedule, confirms each month that it ran against the full scope of in-scope systems, and reviews the results. Findings are triaged: genuine plain-text credentials are logged as issues, the affected credential is rotated (since it must be assumed exposed) and moved into an approved secure store, and false positives are recorded so they do not consume time again next month.

Scope maintenance is the main ongoing effort. New servers, repositories, shares, containers and cloud accounts need to be added to the scan targets as they appear, otherwise the monthly scan quietly covers less and less of the environment. Scan results and remediation records should be kept so that trends can be tracked over time and evidence is available when needed. Where the same source keeps producing findings, the root cause (for example a team's deployment practice) should be addressed rather than just cleaning up the symptom each month.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the scan schedule and the run history for the last six to twelve months.

    Look at

    Check the dates of each completed scan and whether any month was missed or a run failed without being repeated.

    Good evidence

    There is a completed scan for every month, with any failed runs re-executed within the same month.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for the list of systems and locations included in the scan scope, alongside the organisation's asset inventory.

    Look at

    Compare the two to see whether servers, repositories, shares, databases and backups are all covered, and whether recently added systems appear in the scope.

    Good evidence

    The scan scope matches the asset inventory, and there is a documented process for adding new systems to it.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the scanning tool's configuration or ruleset.

    Look at

    Look at what types of credentials it is set to detect, such as passwords, API keys, tokens and private keys, and where in the systems it looks.

    Good evidence

    The tool is configured to detect a broad range of credential types across file systems, code, configuration and data stores, not just one narrow pattern.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for the scan reports and the findings register from the last few months.

    Look at

    Trace several findings from the report to a ticket, and check whether the credential was removed from the clear, rotated and relocated to a secure store.

    Good evidence

    Each confirmed finding has an owner, a remediation record showing removal and rotation, and closure confirmed by a later scan.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask who owns the monthly scan and what they do when results arrive.

    Look at

    Check the documented procedure for reviewing results, triaging false positives and escalating repeat findings to root cause.

    Good evidence

    A named owner reviews results within a set timeframe, false positives are recorded, and recurring sources are addressed at their root rather than cleaned up repeatedly.

Mappings

Closest match in ISO/IEC 27001: A.5.17, Management of authentication information, which this control partially meets.

ISO 27001

ISO/IEC 27001: 2 mappings

  • A.5.17Management of authentication informationPartially meets
  • A.8.12Data leakage prevention measuresPartially meets
Essential Eight

ASD Essential Eight: 1 mapping

  • E8-RA-ML2.5Long, unique, and managed credentials for admin accountsSupports
ASD Essentials

ASD Essentials for enterprise IT: 1 mapping

  • IT.PRO-13.3Run regular secret scanning and rotate or revoke exposed credentialsPartially overlaps

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.