Timestamp Request is an ICMP message that asks a host for its current time values. Attackers may use it for reconnaissance or clock comparison, while defenders generally disable responses and monitor for legacy ICMP queries that reveal system presence or timing information.
What a Timestamp Request does
A Timestamp Request is an ICMP query used to ask a host for its current time values. It is a legacy diagnostic message, but it can still expose whether a system is reachable and how its clock behaves, which is why many environments treat it as unnecessary network noise rather than a useful service.
Why Timestamp Requests matter in security operations
On modern networks, the main value of a Timestamp Request is often defensive visibility. If a host answers, the response can confirm that the system is alive, reachable, and willing to disclose timing information that may help an attacker profile the target or compare clock skew across systems. That makes it part of the broader class of low-signal reconnaissance traffic that security teams may want to suppress or tightly monitor.
Because ICMP is frequently used for diagnostics, operators sometimes overlook older message types that are not needed for business function. A Timestamp Request is especially useful to defenders as a sign of legacy exposure, permissive host policy, or inconsistent edge filtering when such queries should not be accepted.
How responders should interpret exposure
Exposure is usually a network policy question, not an application question. If a system responds to timestamp queries, the issue is less about the ICMP message itself and more about what that response reveals to someone mapping the environment. Review perimeter rules, host firewalls, and segmentation controls to understand where these messages are allowed and whether the behaviour is intentional.
For operators doing asset review, the key question is whether the responding host needs to support this ICMP type at all. In most enterprise settings, the safer assumption is that it does not. If legacy devices or monitoring tools still depend on it, that dependency should be explicit and narrow, not left open by default.
Practical defensive handling of legacy ICMP queries
Defenders generally reduce risk by disabling unnecessary ICMP timestamp responses, filtering the message type where policy allows, and watching for repeated probes that may indicate reconnaissance. The goal is not to break legitimate network diagnostics, but to avoid offering timing and presence signals that do not help normal operations.
It is also useful to distinguish harmless diagnostics from pattern-based enumeration. A single timestamp query may be incidental; repeated queries across many hosts can indicate scanning for live systems, reachable subnets, or timing behaviour that could support later attack planning.
Risk and Threat Considerations
Timestamp Requests are low-level, but they still create a small reconnaissance surface. When hosts answer them, attackers can use the response to confirm reachability, observe time-related behaviour, or build a more detailed picture of the target network before moving to higher-value probing.
Failure mechanism: A host that answers legacy ICMP queries reveals unnecessary information and may signal permissive filtering or inconsistent hardening, which helps an attacker separate live systems from dead ones and refine follow-on scanning.
Impact: The immediate impact is improved attacker intelligence, not direct compromise, but that intelligence can reduce the cost of later reconnaissance and make other discovery or exploitation steps more efficient.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Legacy ICMP query handling is a least-functionality decision for hosts and network services. |
| SC-7 — Boundary Protection | Filtering timestamp replies at trust boundaries is a boundary-protection control. | |
| SI-4 — System Monitoring | Repeated ICMP timestamp probes are a monitorable reconnaissance indicator. | |
| Recommendation — Restrict unnecessary ICMP message types and remove legacy exposure where the protocol is not required. Filter or block ICMP timestamp traffic at network boundaries and segmented zones. Monitor for repeated ICMP timestamp probes as part of reconnaissance detection. | ||
Practitioner Guidance
What to watch for: Treat unexpected timestamp responses as a policy and hardening signal. If the message type is not required, suppress it consistently across hosts and network boundaries, and verify that monitoring still catches repeated probes or unusual ICMP patterns.
Practitioner takeaway: Timestamp Requests are usually a legacy detail, but legacy details often become reconnaissance aids when they are left visible at scale.
Related resources from NHI Mgmt Group
- What breaks when every authorization request is evaluated at a fully consistent timestamp?
- What is the difference between network trust and request-level identity trust?
- Why do access-request workflows matter for NHI governance?
- How should organisations use AI in access request approval without weakening control?