A maintenance group is a set of assets with similar characteristics that generally share the same software maintenance needs. Instead of setting a deadline per asset, you set a plan per group. NIST SP 800-40 Rev. 4 recommends this, and it gives unpatchable systems a home instead of a pile of exceptions.
The definition
NIST describes a maintenance group as a set of assets with similar characteristics that generally have the same software maintenance needs for each risk response scenario. Maintenance needs cover patch schedule, patch testing needs, outage restrictions, level of impact if compromised, and other mitigations such as temporary measures when patches are not yet available.
Organizations choose the granularity that suits them and reassess it periodically.
Why groups beat per asset rules
Per asset deadlines do not scale. Groups let you answer the same questions once:
- How fast must patches be applied in each scenario (routine, emergency)?
- What testing is needed first?
- What outage windows apply?
- What mitigations are pre approved if no patch exists?
NIST adds an important point: instead of calling certain assets exceptions, create maintenance groups for them. An asset that cannot or should not be patched still has maintenance needs, so it should belong to a group with its own plan.
Examples from the guide
NIST's simplified examples include mobile workforce laptops, an on premises data center, legacy operational technology, smartphones, servers for automated software testing, and containers with customer facing applications in the public cloud. Each lists what to patch, outage restrictions, existing mitigations, and impact if compromised.
For an application team, a parallel set might be: public facing services, internal services, build and CI systems, developer tooling, and base container images.
A template
| Field | Public facing services (example) | Legacy components (example) |
|---|---|---|
| What gets patched | Dependencies and images | Nothing, vendor stopped patching |
| Routine plan | Regular release cycle | Not applicable |
| Emergency plan | Canary then full rollout | Isolate, restrict access |
| Outage rules | Rolling, no downtime | Scheduled windows only |
| Existing mitigations | Gateway, monitoring | Network isolation |
| Impact if compromised | High | High |
| Review | Each quarter | Each month, replace plan |
How to start
- List your assets and what they run, using an inventory.
- Sort them by shared traits: exposure, impact, outage tolerance, who patches them.
- Write one plan per group for routine and emergency cases.
- Assign each asset to exactly one group.
- Review the groups regularly, and move assets as they change.
Do not start with twenty groups. Three to six is usually enough at first, and you can split a group when you see a real difference in how it must be handled.
Link groups to deadlines
Once groups exist, a vulnerability policy can say "urgent items in a public facing group follow the emergency plan." That is simpler to apply and to audit than a rule per asset.
Quick check
Is a maintenance group the same as an asset tag?
A tag describes an asset. A maintenance group ties a set of assets to a plan for how they are maintained.
Where do unpatchable systems go?
NIST recommends they have a maintenance group of their own, with mitigations such as isolation, not a growing list of exceptions.
Safeguard's asset discovery and SBOM features can help build the inventory that groups depend on. A free scan is available at gold.safeguard.sh/scan.
Sources
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning (also available as a PDF)
Last reviewed: 19 October 2026.
