No, deadlines should not be identical, but dev is not exempt. Set fix targets by exposure and the data a system can reach, not by its environment label. Many "dev" systems are internet reachable or hold copies of real data, and those deserve production grade deadlines.
What the guidance supports
NIST's guide to enterprise patch management presents patching as a risk managed, organisation wide activity and recommends a strategy that simplifies and operationalises it. It does not say every system gets one number of days. Risk based tiers are consistent with that framing, as long as the tiers are written down and applied evenly.
Define the tiers by facts
| Tier | Typical traits | Example target posture |
|---|---|---|
| Critical exposure | Internet reachable, holds customer data, or listed in a known exploited catalog | Fastest deadline, treated as urgent |
| Standard | Internal, production data or production adjacent | Normal cycle |
| Contained | No real data, no external reach, easily rebuilt | Relaxed cycle, still bounded |
Your organisation sets the actual numbers. This post does not suggest a figure because the right one depends on your change process and risk appetite.
Four checks before you relax a dev deadline
- Is it reachable from outside? A public preview environment is production for attackers.
- Does it hold real data? Teams copy production data into test systems more often than they admit.
- Does it hold credentials? A dev account with deploy rights to production is a path in.
- Can it reach production? Network and identity links matter more than the label.
If any answer is yes, move it up a tier.
Known exploited flaws override the tier
CISA describes its Known Exploited Vulnerabilities catalog as an input to vulnerability prioritisation, and each entry carries a due date and required action. If a component in your estate matches an entry, treat it as urgent in every environment where it is reachable, and decide for the rest case by case.
Write the policy once
State tier definitions, deadlines, who can approve an exception and how long exceptions last. Apply it to all accounts and sites so a hybrid estate does not end up with several inconsistent rulebooks.
An example of a label that lies
A team creates a "dev" environment for a customer preview. It is reachable from the internet, it loads a recent copy of customer records so demos feel real, and its deploy role can push to production. By the four checks above it is a production grade system with a dev label, and it should carry the fastest deadline. Auditing for these cases once per quarter is usually enough to catch them.
Quick check
Is it fine to skip dev entirely?
No. Unpatched dev systems are a common stepping stone and a common source of leaked test data. Give them a longer but real deadline.
Who approves a longer deadline?
The service owner proposes it and a named security approver accepts it, with a reason and an end date recorded.
Safeguard's policies, gates and guardrails let you encode tiered rules as checks, so they apply the same way everywhere. A free scan is at gold.safeguard.sh/scan.
Sources
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- CISA Known Exploited Vulnerabilities Catalog
Last reviewed: 19 October 2026.
