ASD ISM 2143Unique Per-Application Credentials Not Shared Across Environments
Every application and workload gets its own credentials, never reused by another application or workload, and never carried between development, testing, staging and production.
Plain language
Applications and workloads (services, containers, batch jobs, integrations, service accounts) authenticate to databases, APIs, queues and other systems using credentials such as passwords, API keys, tokens, certificates or client secrets. This control requires two things. First, each application or workload has its own credentials that no other application or workload uses. Second, those credentials are not reused across environments, so the development, testing, staging and production copies of the same application each have distinct credentials. Why it matters: shared credentials collapse security boundaries. If two applications share a database password, compromising the weaker one gives an attacker the stronger one's access, and you cannot tell from logs which application actually performed an action. If a production secret is also used in development or testing, it sits in places with weaker protection (developer laptops, test fixtures, CI logs, sample data, screenshots in tickets) and a leak there becomes a production breach. Unique credentials keep the blast radius of any single compromise to one application in one environment, make every action attributable, and let you revoke or rotate one credential without breaking anything else.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for system accessSection
Credential managementTopic
Application and workload credentials
Official control statement
Applications and workloads use unique credentials that are not shared with other applications or workloads, or across development, testing, staging and production environments.
Why it matters
A single leaked or compromised credential could grant access to several applications or workloads at once, or turn a development or test compromise into a production breach. Investigations cannot reliably attribute actions to a specific application, and revoking a compromised credential forces outages across every application that shared it.
Operational notes
Day to day, this control lives in how new applications, workloads and environments are provisioned. Whenever a team stands up a new service, integration, scheduled job or environment, the request should create a fresh credential for that application in that environment, rather than copying one that already exists. Secrets management tooling makes this practical: store credentials per application and per environment, reference them by name from deployment configuration, and prevent the production secret path from being readable by development or test pipelines.
Watch for the common ways sharing creeps back in: a "generic" service account reused by several jobs because it already has the right permissions, a production connection string copied into a test config to reproduce a bug, environment variables cloned when a new environment is spun up from an existing one, or a vendor integration that reuses one API key across every tenant or environment. Include a credential-uniqueness check in change reviews and environment build checklists, and reconcile the secrets inventory against the list of applications and workloads periodically so that orphaned or shared entries are found and split. When an application is decommissioned, its credentials are revoked without affecting anything else, which is itself a useful sign the control is working.
Implementation tips
- Application owners and platform engineers inventory every application and workload, together with the databases, APIs, queues and service accounts each one authenticates to, and record which credential is used in each of development, testing, staging and production so that any credential appearing more than once is visible.
- Platform engineers configure the secrets manager (or vault) with a separate entry for each application in each environment, using a naming scheme such as app/environment/purpose, and have deployment pipelines inject the credential by reference so the value never needs to be copied between configurations.
- Platform engineers scope access to secrets by environment, granting development and testing pipelines and developers read access only to their own environment's secrets, and restricting production secrets to the production deployment identity.
- Development teams update environment build and onboarding procedures so that creating a new environment or new workload always generates new credentials (new service account, new API key, new client secret) instead of cloning environment variables or configuration files from an existing environment.
- Application owners split any credential found to be shared, by issuing a fresh credential for each additional application or environment, updating each consumer to its own credential, then revoking the previously shared one once all consumers are migrated.
Audit / evidence tips
- AskAsk for the inventory or secrets manager listing of application and workload credentials, mapped to the applications and environments that use them.Look atCheck whether any single credential, service account, API key or certificate is listed against more than one application or workload.GoodEach application or workload has its own distinct credential, and the listing shows no credential consumed by two or more applications.
- AskAsk for the credential entries for one application across its development, testing, staging and production environments.Look atCompare the credentials (or their identifiers and fingerprints, not the secret values) across the four environments to see whether the same one is reused.GoodThe application uses a different credential in each environment, and the production credential does not appear in any non-production configuration.
- AskAsk for the deployment pipeline configuration and the access policy on the secrets store.Look atLook at how credentials are supplied to each environment and which identities can read the production secrets.GoodPipelines pull environment-specific secrets by reference, and non-production pipelines and developers cannot read production credentials.
- AskAsk for the procedure used to stand up a new environment or a new workload, and a recent example of it being followed.Look atCheck whether the procedure requires new credentials to be created, or whether it clones configuration and environment variables from an existing environment.GoodThe procedure creates fresh credentials for every new workload and environment, and the recent example shows a new credential was issued rather than an existing one reused.
- AskAsk for records of the last review that reconciled credentials against applications and environments, and any remediation that followed.Look atLook for shared credentials that were identified, the fresh credentials issued to replace them, and revocation of the previously shared credential.GoodShared credentials are found and split as part of a repeatable review, with evidence that the old shared credential was revoked after each consumer moved to its own.
Cross-framework mappings
How ISM-2143 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 5.17 | ISM-2143 requires each application/workload to have unique credentials that are not reused across other applications or across developmen... | |
sync_altPartially overlaps(1)expand_less | ||
| Annex A 8.31 | ISM-2143 requires credentials to be unique per application/workload and not shared across development, testing, staging and production | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System access
See all Guidelines for system access controls, or browse the full ASD ISM library.