What are the best practices for tag naming conventions?
This article describes recommended tag conventions for organizing assets in Security Center. Tags are the foundation of asset organization, and they enable accurate scoping, role-based access, targeted scan scheduling, and clear reporting.
To learn more about what a tag is and how it works - read this article.
Recommended tag hierarchy
Use a three-level hierarchy as your default starting point. Flatten only if your environment is genuinely simple.
| Level: | Example: | Purpose: |
|---|---|---|
| L1, Location | EU-SE, US-EAST, CLOUD-AWS | Broad grouping by geography or hosting type. Drives scan routing to the correct Scanner Appliance and supports regulatory scope separation, e.g., GDPR vs. HIPAA. |
| L2, Business unit | IT-OPS, FINANCE, DEV, OT | Maps to your organizational structure. Used for role-based access boundaries, where each team typically sees only their own L2 tag. |
| L3, Asset type | WIN-SRV, LINUX-WEB, NETWORK, K8S-NODE | Granular classification for targeted scan profiles and remediation routing. Determines which scan profile to apply. |
Tag naming rules
- Use uppercase with hyphens. For example, "EU-SE-WIN-SRV" is easier to read and filter than "euseWinSrv" or "eu_se_win_srv." Consistent casing prevents duplicates caused by capitalization differences.
- Avoid spaces and special characters. Spaces break API filters and CSV exports. Restrict characters to A-Z, 0-9, and hyphens.
- Keep names short but self-explanatory. Tags appear in dropdowns and report filters, so names longer than around 20 characters become unreadable. Agree on abbreviations and document them in your IT environment definition.
- Never use generic names. Tags like "TEST," "MISC," or "OTHER" tend to accumulate assets that never get properly classified. Make sure you know what a tag means before you create it.
- Limit hierarchies to three levels. A tag structure can only go three levels deep, parent → child → grandchild, for example EU-SE → IT-OPS → WIN-SRV. Plan your top-level categories with this limit in mind, since a fourth level cannot be added and restructuring later means moving assets to new tags.
Example
A Windows server hosted in your Swedish office and managed by your IT operations team would carry three tags, one from each level: EU-SE (location), IT-OPS (business unit), and WIN-SRV (asset type).
With these three tags applied, you can filter and report on the asset in several ways:
- All assets in EU-SE, regardless of business unit or type.
- All WIN-SRV assets across every location, to review your Windows server exposure globally.
- Only the assets IT-OPS owns in EU-SE, for example to scope a role-based access group.
Because each asset carries all three tags at once rather than being nested under a single parent tag, you can combine any level with any other to build the view you need.
Dynamic vs. static tags
Prefer dynamic, rule-based tags over static, manually assigned tags wherever possible. Dynamic tags automatically classify assets.
Importing tags via the API
Tags can also be imported directly via the Application Programming Interface (API). This is useful if you already maintain asset classifications in an external system, such as a Configuration Management Database (CMDB), and want to keep your tag structure in sync without assigning tags manually in Security Center.
To get started with tags read this article about how to create a tag.