ASD Put Your Credentials in the Asset Register

Read the Identify principles in the June 2026 ISM carefully and one of them does something the others do not.

Almost every principle in the document defines its scope the same way: systems (infrastructure, operating systems, applications and data). That phrase repeats through Govern, Protect, Detect, Respond and Recover, near-verbatim, dozens of times.

IDE-01 is different.

IDE-01 — Asset identification Systems (infrastructure, operating systems, applications, identities, credentials and data) are continually and centrally identified and documented.

Two words were added to the standard formula, and only here. Identities. Credentials.

ASD is telling you that a credential is an asset, that it belongs in the register, and that the register must be continual and central. Not a spreadsheet someone refreshes before an audit.

Now open your register and look for them

Not the user accounts. The machine credentials. The deploy tokens. The Azure service principals. The API keys with write access to a core integration. The legacy integration account created for a project that closed two reorganisations ago and still authenticates every night.

In most Australian institutions they are not there. And the register is presented to the board as complete.

The reason is structural, and worth stating without hedging: your identity programme was designed for humans. You cannot apply multi-factor authentication to a token — it has no second factor and nobody to challenge. You cannot run a leaver process on a service account; it never resigns. You cannot certify either in an access review, because no manager knows what it is for or what still depends on it.

The ISM anticipates this. PRO-13 requires identity, credential and access management that supports effective detection of identity and credential misuse. PRO-12 extends least privilege explicitly to personnel and services — not just people. DET-04 requires baselines of identity and credential access activity so that anomalies can be detected at all.

Two controls that would have prevented this quarter’s worst failure

In May 2026, the United States agency that issues vulnerability-management directives to its own government discovered that administrative keys to its cloud estate were public. It found out when a journalist emailed for comment.

The repository was named Private-CISA. Reporting across Krebs on Security, TechCrunch and Cybernews describes roughly 844 megabytes: AWS GovCloud administrative credentials, access tokens, Entra ID SAML certificates, plaintext passwords in a CSV, CI/CD build logs, Kubernetes manifests and Terraform. A researcher tested a sample of the credentials; they worked. The repository belonged not to CISA but to a contractor, who had copied a build-and-deployment repository into a personal GitHub account — and had switched off the setting designed to prevent secrets being published.

Now read the control that setting corresponds to:

The ISM already required both halves of the fix

ISM-2030: Scanning is used during commits to identify plain text or encoded secrets and keys, which are then blocked from being stored in the authoritative source for software. This is precisely the control the contractor disabled.
ISM-1875: Networks are scanned at least monthly to identify any credentials that are being stored in the clear.
ISM-1590: credentials are changed if they are discovered stored on networks in the clear — or if they are compromised, or suspected of being compromised.

The guidance was not missing. The control was switched off, on an account nobody was watching, on infrastructure outside the boundary.

The gap ISM-2030 and ISM-1875 cannot close

Both of those controls are inward-facing. ISM-2030 scans your authoritative source. ISM-1875 scans your networks. Neither would have found the CISA repository, because the repository was on a contractor’s personal GitHub account — not on CISA’s networks, not in CISA’s authoritative source, and not within scope of any control CISA operated.

This is where the June 2026 ISM does something genuinely useful, because it pairs IDE-01 with a principle pointing the other way:

GOV-10 — System exposure minimisation: Information about the design, configuration and operation of systems is not publicly disclosed or shared externally unless necessary… with any disclosure minimised, controlled and logged.

A credential in a public repository is information about the configuration and operation of a system, publicly disclosed. GOV-10 covers it. And GOV-10, unlike ISM-2030 and ISM-1875, cannot be satisfied by scanning inward. It requires you to look at yourself from where the credential actually is.

The asymmetry, stated plainly Machine credentials are the one privilege class that routinely escapes into places anyone can look. An over-permissioned Active Directory group is invisible from the internet. A deploy token in a contractor’s repository is not. For once, the attacker and the defender are looking at the same data — and in most organisations only one of them is looking.

The provider problem, and the control nobody exercises

Two of this quarter’s three credential failures originated with a provider. The ISM has a control for that, and it was revised in June 2026:

ISM-1571: the right to verify compliance with security requirements is documented in contractual arrangements with service providers.
ISM-1738 (Revision 2, June 2026): that right is regularly exercised.

Read those together. ASD has separated having the right from using it — and has made using it the control. A contract clause you have never invoked is not assurance. It is paperwork.

GOV-11 makes the same point at principle level: systems are delivered and supported by trustworthy suppliers whose cyber security practices are regularly independently verified or otherwise risk-assessed. Independently. Not self-attested.

A note on the ISM’s statusThe ISM states plainly that an organisation is not required as a matter of law to comply with it unless legislation, or a direction under legislation or other lawful authority, compels them to. It is advice, not statute. But it is the advice ASD gives, the foundation the Essentials series is being built on, and the document an IRAP assessor works from. Treating it as optional is a choice you will be asked to defend.

Where this lands under Australian obligations

CPS 234 requires information assets to be identified and classified by criticality and sensitivity. IDE-01 removes any argument about whether a credential qualifies. It does.
CPS 230, in force since 1 July 2026, requires entities to manage risks arising from material service providers. ISM-1738 tells you what managing it looks like: exercise the verification right, regularly.
Essential Eight, and its ISM-grounded successor. Restricting administrative privileges is the obligation. A deploy credential with cloud-administrator scope is an administrative privilege.

Four questions for a board

How many non-human identities do we hold? A number, not an estimate. IDE-01 says the register is continual and central.
Is ISM-2030 enabled across every repository we control — and every repository our contractors use for our work?
When did we last exercise our right to verify a provider’s compliance? (ISM-1738) If the answer is never, we hold a clause, not a control.
Could we establish that none of our credentials is currently public? If not, the defensible assumption is that some may be.

None of this quarter’s incidents were sophisticated. All were the same failure: a credential belonging to a machine, held outside the boundary anyone was watching, governed by nobody, and still valid. ASD has now named credentials as assets. The question is whether your register has caught up.

None of this is in the Essential Eight IDE-01 has no Essential Eight mapping. Neither does ISM-2030 (block secrets at commit — the control CISA’s contractor disabled), nor ISM-1875 (scan networks monthly for credentials stored in the clear), nor ISM-1738 (regularly exercise your right to verify a provider’s compliance).

The Essential Eight tells you to patch and to scan for missing patches. It has nothing to say about whether your credentials are already public, or whether you have ever checked your provider. Of the ISM’s 1,101 controls, 126 map to the Essential Eight. Every control in this article sits in the other 975. The arithmetic is here.

ASD Put Your Credentials in the Asset Register.
Yours are not in it — and machine credentials are the one privilege class that leaks into public view.

Now open your register and look for them

Two controls that would have prevented this quarter’s worst failure

The ISM already required both halves of the fix

The gap ISM-2030 and ISM-1875 cannot close

The provider problem, and the control nobody exercises

Where this lands under Australian obligations

Four questions for a board

Sources & references

Are Your Credentials in the
Register, or in Public?

ASD Put Your Credentials in the Asset Register.Yours are not in it — and machine credentials are the one privilege class that leaks into public view.

Now open your register and look for them

Two controls that would have prevented this quarter’s worst failure

The ISM already required both halves of the fix

The gap ISM-2030 and ISM-1875 cannot close

The provider problem, and the control nobody exercises

Where this lands under Australian obligations

Four questions for a board

Sources & references

Are Your Credentials in theRegister, or in Public?

ASD Put Your Credentials in the Asset Register.
Yours are not in it — and machine credentials are the one privilege class that leaks into public view.

Are Your Credentials in the
Register, or in Public?