(This article was updated on the 13 May 2025.)
The asset naming conventions of the early 2010s were designed for static, on-premises IT infrastructures. Today, organisations operate in highly dynamic environments with widespread remote work, extensive cloud adoption, and increasingly ephemeral workloads driven by containerisation and automation.
This formal guide presents a modern framework for naming IT assets that addresses these hybrid realities.
Enabling Remote and Hybrid Work
Modern IT infrastructures must support employees working remotely, in the office, or a combination of both. In addition, organisations increasingly rely on a workforce made up of both permanent employees and contractors. Naming conventions should account for both access mode (remote, office, hybrid) and role type (employee or contractor) to enable targeted policy enforcement, security monitoring, and inventory reporting.
- Example: ONP-RMT-EMP-WKS-3421 — An on-premises workstation primarily used by a remote permanent employee.
- Example: ONP-OFF-CTR-WKS-R1-3421 — A workstation assigned to a contractor working on-site in the London office.
- Example: CLD-HYB-EMP-VDI-WEU-8192 — A cloud-hosted virtual desktop accessed in a hybrid pattern by a permanent employee.
Standardising Cloud-Native Resource Names
Cloud resources can span multiple regions, accounts, and platforms. A standardised naming convention ensures consistency and clarity for cost management, security auditing, and operational oversight.
- Example: CLD-HYB-APP-WEU-0132 — A cloud-based application deployed in Western Europe.
- Example: CLD-RMT-DB-USE2-983A — A cloud-hosted database in the US East 2 region.
Accommodating Containers and Ephemeral Resources
Ephemeral workloads—such as containers, serverless functions, and short-lived VMs—require naming practices that support traceability. These names should be designed to remain meaningful even after the asset has been deprovisioned.
- Example: CNT-HYB-API-PAY-V1-X9A3D — A container instance running the payment API.
Reinforcing Policies and Automation
A robust naming convention supports policy enforcement and automation across environments. It can be enforced through IaC tools, CI/CD pipelines, and cloud policy engines to ensure consistent compliance.
Integrating Privacy, Security, and Compliance
Asset names should avoid revealing sensitive or identifiable information. Names should never include usernames, business functions, or cloud provider names. If wishing to tag by provider name (e.g. AWS, Azure), create public obfuscated location codes and map internally.
- Risky Example: AWS-London-Finance-DB-JaneSmith
- Recommended Example: CLD-OFF-DB-R1-FIN-02F8
Obfuscating Location Identifiers: Pros and Cons
While using readable location codes can help operational teams, they can also expose your infrastructure layout. Obfuscation helps reduce risk.
- Pros: Easier troubleshooting and compliance segmentation.
- Cons: Increased external exposure and risk of targeted attacks.
Recommendation: Use codes like R1, R2 and maintain a private mapping internally.
Internal Location Code Mapping Table Example
| Obfuscated Code | Actual Location | Region/Time Zone | Notes |
| R1 | London, UK | Europe/London | Primary EU datacenter |
| R2 | New York City, USA | America/New_York | Core East Coast site |
| R3 | Sydney, Australia | Australia/Sydney | Asia-Pacific users |
| R4 | Frankfurt, Germany | Europe/Berlin | GDPR-compliant infrastructure |
| Z1 | Tokyo, Japan | Asia/Tokyo | Low-latency APAC workloads |
| Z2 | São Paulo, Brazil | America/Sao_Paulo | South American presence |
| X1 | Internal VPN Zone | N/A | Not location-specific |
| X2 | Global CDN / Edge Nodes | Multiple | Used for caching proxies |
| C1 | Azure | As per location code (e.g. USW1) | Workload running in the Azure US West 1 datacenter |
Appendix: Real-World Asset Name Examples
| Asset Name | Description |
| CLD-RMT-EMP-WKS-R2-983F | Cloud-managed workstation for remote employee based in R2 (New York) |
| ONP-OFF-CTR-WKS-R1-0023 | On-premises desktop for contractor in R1 (London) |
| CLD-HYB-EMP-APP-R4-44D8 | Cloud app accessed by hybrid-mode employees in R4 (Frankfurt) |
| CNT-HYB-SYS-API-Z1-V1F2 | System-owned container API in Z1 (Tokyo), hybrid accessibility |
| ONP-OFF-SYS-DC-R1-0001 | On-prem domain controller in London |
| CLD-RMT-EMP-VDI-R3-A7E1 | Virtual desktop for remote employee in Sydney |
| CLD-HYB-EMP-DB-R2-5C9B | Cloud database accessed by hybrid employee base in New York |
| CLD-OFF-EMP-WEB-X2-DF19 | Web server on global edge (X2), accessed from office networks |
| CLD-RMT-CTR-WKS-X1-AB43 | Contractor’s remote laptop via VPN zone (X1) |
| CNT-RMT-SYS-JOB-Z2-31F8 | Remote job-running container in São Paulo (Z2), used by backend service |
One interesting
point I soon discovered on naming conventions is to make sure that the prefix you choose to delineate the characteristics of a data field
should be the same length. Then when you export the data and wish to split into columns it will be much easier to do if there isn’t a
unique delineator present (eg. “_” “.”). So in the example Nir quotes, if there is also a Detroit branch, then the shortened version of
Detroit should also be just two letters. If you then need to split into columns you just set the split at between characters 2 &
3.
Be careful with naming conventions that include locations or departments. Users and equipment move more often than you
think. We have server names that include the abbreviation of a data center we moved out of 4+ years ago.
Would not it be simpler to use only the number of patrimony? And to know where the equipment is physically used to register the property, for example in the ERP.
Thanks for the information ….
It helped me a lot to define the User name and Desktop name in my orz.
You should not use anything that will change and cause you to have to touch the device. So using user names is not a good idea when you support 5000 users. You would be spending a lot of wasted time re-naming devices when the users change. Phone numbers also change. If you have 20 users then it doesn’t matter, but anyone who supports a lot of folks know that it is important to limit touch. By using a person’s name you are only creating more work for yourself down the line.
Shawn
When a device is shared by multiple users it is not recommended to include a single user’s name in the device naming convention.
If a device is reallocated to a different user, my advice to rename the device, and further than that, I would recommend reinstalling the device. the deployment tools that are utilized in large scale organizations, such as SCCM or MDT, are usually customized to allow a very quick reinstall with all settings included. withing the installation, thus making the reallocation a simple process. This method ensures you get a clean computer with no piggybacks of accumulated settings made by the previous user, making it faster and secured, and protected of privacy violations with previous user’s data.
Very large enterprises use assetID or CMDB’s CI ID as the device name, this might solve the renaming, but I would still recommend reinstalling the device before reallocating it.
Nir
Shawn
When a device is shared by multiple users it is not recommended to include a single user’s name in the device naming convention.
If a device is reallocated to a different user, my advice to rename the device, and further than that, I would recommend reinstalling the device. the deployment tools that are utilized in large scale organizations, such as SCCM or MDT, are usually customized to allow a very quick reinstall with all settings included. withing the installation, thus making the reallocation a simple process. This method ensures you get a clean computer with no piggybacks of accumulated settings made by the previous user, making it faster and secured, and protected of privacy violations with previous user’s data.
Very large enterprises use assetID or CMDB’s CI ID as the device name, this might solve the renaming, but I would still recommend reinstalling the device before reallocating it.
Nir