# Keep production authority separate from everyday development

Environment names do not create an access boundary. Verify who can change production, how that authority is obtained and where its use is recorded.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Map people and service identities separately

List the developers, operators, pipelines and runtime services that access production. Each needs a purpose and a scope appropriate to its work.

A developer may need to inspect logs without changing infrastructure. A deployment pipeline may need to update the application without reading its customer data. A runtime identity should not inherit the pipeline's ability to alter the environment.

Avoid treating one shared administrator role as the answer to all three needs.

## Review how authority is obtained

Use the organisation's supported identity and approval mechanisms for elevated access. Define duration, authentication requirements and the evidence recorded when someone obtains it.

Test the ordinary path and the emergency path. Emergency access should remain usable during the failures it is meant to address, with appropriate controls and review.

Do not assume an account or subscription boundary alone establishes least privilege. The identities and cross-boundary grants determine what people and services can actually do.

## Follow data into shared services

Central logging, monitoring and backup systems may receive production information from many workloads. Review who can read those shared destinations.

A central platform operator may need infrastructure diagnostics without unrestricted access to every application's payloads. Choose collection and access policies that reflect that distinction.

Test with synthetic sensitive content to see whether errors or traces include more than intended. A workload's careful response handling does not help if its full request body is copied into a broadly readable log store.

## Verify separation through attempted actions

Use representative identities to attempt an allowed read, a prohibited change and an approved deployment. Inspect the actual result and audit evidence.

Include cross-environment mistakes, such as a test pipeline targeting production. The control should prevent the action even if someone supplies the wrong resource identifier.

Record any remaining broad grants with their reason and owner. The review should end with an access model that can be demonstrated, rather than a diagram whose production box merely uses a different colour.

## Sources

- [OWASP: authorisation guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)
- [AWS: service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)