The open standard EnvSpec Naming 1.0.0 argues that traditional host naming practices undermine security long before firewalls are configured. It claims that any environment labelled test, uat or pilot that processes real data is functionally prod and must be protected accordingly.
The specification defines a five-level hierarchy—environment, perimeter, system, slot, node—and mandates the canonical FQDN format {node}.{slot}.{system}.{perimeter}.{env}.{domain}. Names must be parseable by regular expressions and validating webhooks, allowing policies to be written against name suffixes rather than IP lists.
Only six environments are permitted: dev, test, stage, prod, infrastructure and workplace. Sandboxes, load-testing and pilot projects are treated as contours inside these environments, not new top-level categories. The decisive criterion is the nature of consumers and data, not hardware or project phase.
Key trust rules include: linear environments may not communicate directly; infrastructure alone may exchange artefacts and telemetry with all tiers; workplace devices reach any environment only via an access gateway; external parties are represented as external.{env} contours.
The standard explicitly forbids encoding mutable attributes such as site location, SLA or lifecycle status in names. It projects the same hierarchy into SPIFFE IDs, Kubernetes namespaces and three mandatory tags: envspec.io/env, envspec.io/perimeter and envspec.io/system.
Compliance can be verified automatically without maintaining a separate CMDB. Existing legacy hosts do not require renaming; applying the three tags at the hypervisor or cloud layer is accepted as full conformance.
