How T1601 Modify system image shows up on network devices
A SOC lead's most common blind spot on a switch, router or firewall is the assumption that the firmware running on it is the image the vendor shipped. Firmware and system images form a trusted layer beneath the operating system, and most teams never hash, compare or regularly review them after deployment. That trust is what Defense Impairment exploits. MITRE describes the tactic as adversaries trying to break security mechanisms, pipelines and tooling so that defenders cannot see or trust what is happening. The tactic, TA0112, was added in ATT&CK v19 when the Enterprise Defense Evasion tactic was split. The remaining evasion behavior keeps the ID TA0005 under the name Stealth, and impairment behavior moved to TA0112. Technique T1601, Modify system image, sits in that new tactic and matters most on network devices, where a changed image can be hard to see from the host side.
At a high level, T1601 changes what a device boots and runs. ATT&CK divides it into two sub-techniques by concept: altering the code inside a system image, and loading an older image that carries known weaknesses in place of the current one. Both can leave the device looking normal in day-to-day operation, so the detection case rests on change records, image integrity and who made the change, not on symptoms. This page targets Enterprise ATT&CK version 20.0, released on October 13, 2026. Because MITRE can rename, deprecate or revoke techniques between releases, confirm the sub-technique names and IDs against the version you map to before you write any rule.
For the network team, the first decision is inventory. List which platforms in your estate accept image or firmware uploads, who is authorized to perform them, and where known-good image hashes are recorded. Ask each vendor to confirm which image integrity and signing features its devices support and how image events are logged, because those answers determine which telemetry you can rely on. Then tie the work to the mitigations ATT&CK maps to this technique, Privileged Account Management and Multi-factor Authentication, so that only named administrators with strong authentication can change images. Rehearse the detection in a private cyber range before relying on it in production. Check the ATT&CK updates page for the version you target.
Which telemetry reveals a modified system image
This table maps the two data components most relevant to T1601 Modify System Image, Command Execution (DC0064) and File Modification (DC0061), to the signals a defender should look for on network devices. Read each row as a signal, the collection path that can carry it, and the vendor dependency that decides whether it is visible at all.
| Signal | What to look for | Collection path | Coverage note |
|---|---|---|---|
| Image or firmware file change (DC0061) | Unexpected change to a stored system image, boot image or firmware file, including a version that does not match the approved baseline | Device configuration backups compared in version control, or file integrity events forwarded by syslog into Wazuh | Depends on whether the vendor exposes image hashes or file change events; confirm with the vendor |
| Privileged command around an image change (DC0064) | Administrative commands that copy, install or activate an image shortly before a reload or reboot, run by an unexpected account | Syslog forwarding of AAA and command accounting logs into Wazuh, with Zeek or Suricata network context for the management session | Command accounting detail varies by vendor and license tier; confirm which command logs the device emits |
| Unplanned reboot after image activation | A reload or boot event outside an approved change window, followed by a changed software version reported by the device | Syslog boot and restart messages correlated with change tickets in the defender's own record system | Boot messages are common, but the version field may not be logged; confirm before relying on it |
| Management session origin | Administrative sessions to the device from a host outside the approved management network or jump path | Zeek connection logs or Suricata flow records for management ports, compared with an approved source list | Visible only where management traffic crosses a monitored segment; out-of-band management may be invisible |
| Configuration drift after image change | Startup configuration or running configuration differing from the last approved backup after a version change | Scheduled configuration backups diffed in version control, with alerts raised on unexpected changes | Backup export support and frequency depend on the device platform; confirm export methods and retention |
| Image checksum mismatch | A stored or loaded image whose hash does not match the vendor-published value for that version | Hash values recorded in the change record and compared during a scheduled check or after reload | Requires the vendor to publish hashes for the exact image; confirm availability before designing this check |
Detection ideas for modified system images on network devices
T1601 Modify system image leaves a small set of traces on network devices: writes to image or boot files, privileged activity before a reboot, and a running build that no longer matches the approved baseline. The four ideas below target Enterprise ATT&CK 20.0, and each depends on device telemetry reaching a central log store before it can be tuned.
Image or boot file changes
Writes to firmware images, boot loaders or startup files are the most direct signal for T1601 Modify system image. Collect File Modification and Command Execution events from the device or its management platform, and alert on any write to an image or boot path that has no matching approved change record. Tune the window to the maintenance calendar your change board uses, and allowlist the management server that performs scheduled pushes. Expect false positives from scheduled upgrades, staged rollouts and vendor RMA replacements, and tag those events with their change ticket before analysts see them.
Privileged command then reboot
A privileged session that runs image-related commands and is followed by a reboot is worth correlating, because a reboot is how a modified image takes effect. Build the rule on Command Execution events, with a reboot event as the second step in the sequence. Derive the correlation window from upgrade durations in your own baseline, and review it after each platform upgrade. Expect false positives from planned reboots after configuration changes and from engineers troubleshooting a fault. Attach the session identity to each alert so analysts can see who was connected.
Hash and version drift
Compare the running image version and checksum against a known-good baseline built from vendor-published values and your own approved builds. Collect these on a schedule from the device or its management plane, and alert when a device reports a build outside its approved set. Confirm with each vendor whether it publishes image hashes for your models and hardware revisions, since many environments cannot verify without them. Drift also comes from hardware revision differences, failed collection and unapproved hotfixes, so separate those cases before escalation. Keep the baseline under change control so that updating it is itself a logged event.
Changes by unlisted administrators
Reconcile every account that performs an image or boot change against the current privileged roster in your identity platform. An event from an account absent from that roster is a strong signal. Shared and break-glass accounts need their own rule that checks the vault checkout record for the same time window. This control is the operational side of the Privileged Account Management mitigation. Expect false positives from stale roster entries, service accounts used by upgrade tooling and recently rotated credentials. Confirm that device session logs preserve the individual identity, not only the shared login name.
How to validate that the T1601 detection fires
This sequence proves, in a controlled lab, that a deliberate and approved system image change on a network device produces the telemetry, alert and evidence trail the detection is meant to produce. It turns a written detection into a tested control with recorded gaps that the team can fix before a real event.
Agree scope and rules with the network team
The detection owner, the network operations lead and the security lead agree in writing which device or virtual appliance will be used, which image change is permitted, who can see the results and how the test will be stopped. The network team confirms that no production traffic depends on the target. Done means a signed scope note exists and the change window is recorded in the change management system.
Prepare a non-production device or virtual appliance
Use a lab appliance, a spare device or a virtual image that matches the vendor and firmware family in production as closely as the lab allows. Record the current image version, configuration hash and the management account that will be used. Done means the baseline is captured in a file that the team can compare against later, and the device is confirmed to be isolated from production routing.
Confirm logging sources before the change
Before anything changes, the analyst checks that the device's management logs, syslog forwarding and any file integrity or configuration monitoring are reaching the SIEM, such as a Wazuh manager or a Security Onion deployment. The analyst sends a benign test message and confirms it arrives with the correct host name and timestamp. Done means the test message appears in the search index, and any missing source is logged as a gap before the exercise starts.
Perform an approved and logged image change
The network engineer performs the planned image change on the lab device, following the agreed change record and without any attempt to hide the activity. The exact time of the change and the operator account are noted on the change record. Done means the device reports the new image state and the change record is closed with the start and end timestamps.
Confirm telemetry and alert firing
The analyst searches for the events the change should generate, including command execution records, file modification events for the image store and any configuration change logs, and then checks whether the detection rule raised an alert. Each event is matched to the change record by time and host. Done means the analyst can show the event identifiers, the rule identifier and the alert identifier for each expected signal, or documents which one did not appear.
Record timestamps, alert IDs and gaps
The analyst writes a short results table listing the change time, the first event time, the alert time, the alert identifier and the time between the change and the alert. Missing or delayed signals are listed as gaps with a suggested owner. Done means the results are stored with the detection record and reviewed by the detection owner, who decides which gaps need tuning, new log sources or a re-run.
Review the ATT&CK STIX bundle for the target version
Before the next run, the detection owner checks the enterprise-attack STIX bundle for the ATT&CK version the rule targets, confirming that T1601 and its sub-techniques still carry the expected names, data component references and mitigations. Any renamed, deprecated or revoked items are recorded and the rule mapping is updated. Done means the mapping note names the ATT&CK version used and the date of the review.
Why a modified image is hard to see after the fact
A modified system image is hard to see after the fact because the change lives below the layer where most host-based tools look. When a network device boots from an altered firmware or software image, the tampered code runs as if it were the vendor build, so the running configuration, process list and logs can all look normal. Image-level changes can also survive reboots and reimaging workflows that restore from a copy the attacker has already touched, which means the device may appear clean after a routine restart. For this reason, the defender's question is rarely "does the device look wrong?" and more often "does the image it booted from match what we approved?" Teams should confirm, with their device vendor and in their own environment, which integrity verification features their platforms support at boot, and whether those checks can be configured to alert rather than only log.
Answering that question depends on evidence gathered outside the device. Keep a golden record for each image in use: the published file hash from the vendor, the version string, the build date and the approved configuration backup taken at the same change window. Store these copies on a system the device administrators cannot modify, such as a write-once repository or a separate logging host, so an attacker with device privileges cannot rewrite the baseline along with the image. Hashes and backups answer what changed; change tickets answer whether anyone meant it to change. An upgrade that matches an approved ticket, a named engineer, a scheduled window and a hash from the vendor is sanctioned. An image that differs from the baseline with no ticket, or whose hash does not match any published build, is a high-priority investigation. Analysts should also compare the image version reported by the device against the version recorded in the change system, because a mismatch between the two is often the first visible sign of tampering.
The practical decision for a regulated organization is where these baselines live and who may write to them. Assign ownership of the image inventory to a role separate from the people who perform upgrades, and require that every upgrade produce a new baseline entry before the change is closed. Ask your implementation partner and your vendor to document how image hashes are retrieved, verified and stored, and rehearse a case where the baseline itself is missing or disputed, since that is the situation an attacker would aim to create. Retention matters too: confirm how long configuration backups and change records are kept against your internal policy and any external obligations that apply to your sector, because a tampering finding that arrives months later can only be resolved if the older baseline still exists.
Mitigations that limit who can change system images
T1601 Modify System Image is only practical for an adversary who can change the firmware or software image of a network device. The mitigations below cut that exposure in two ways: fewer accounts can make image changes, and every change must be approved, verified and recorded.
Restrict privileged administrative roles
Privileged Account Management (M1026) is the mitigation most directly tied to this technique, because image changes on network devices normally require administrative rights. Inventory every account and group that can upload, stage or boot a device image, then remove standing access that is not needed for current duties. Separate the role that reads device configuration from the role that replaces firmware, and confirm with each device vendor which built-in privilege levels can perform an image update. Review these assignments on a fixed schedule and alert on any new membership in the groups that hold this right.
Require multi-factor authentication for device access
Multi-factor authentication (confirm the mitigation ID on the ATT&CK mitigation page before citing it) makes a stolen password insufficient for logging into management planes, jump hosts and network device consoles. Apply it to every interactive path that can reach an image update function, including vendor management portals and out-of-band consoles. Ask each vendor whether its device management interface supports MFA natively, whether it requires an external identity provider, and what fallback local accounts exist when that provider is unavailable. Local break-glass accounts need their own strict controls and monitoring.
Approve every image change
Require a documented change request, a named approver who is not the person performing the upgrade, and a maintenance window before any image is staged or installed. Record the approved image version, hash and target device in the ticket so that a later image change without a matching record stands out. Use Audit (M1047) logging on the device or management platform to correlate each approved change with the actual event. An image change that occurs outside a window or without a ticket should be treated as a potential incident until it is explained.
Keep signed and verified images
Where the vendor supports it, configure devices to accept only images signed by the vendor and to verify the signature at boot or install time. Store approved images in a controlled repository with restricted write access, and compare the hash of any image before deployment against the value the vendor publishes. Confirm with the device vendor whether secure boot, signed image enforcement and hardware-backed integrity checks are available for each model in your fleet, and which of these are disabled by default.
Monitor the image repository and transfers
Protect the systems that hold, stage and transfer device images with the same privilege controls used for the devices themselves. Watch for unexpected writes to image directories, new image files that match no approved ticket, and transfers from unfamiliar hosts. File Modification and Command Execution telemetry from the staging servers and management hosts are the signals that show these events. Use integrity monitoring on the repository so that a changed file is noticed even when an administrator account was used.
Confirm vendor-specific controls
Each network device vendor exposes different roles, logging and integrity options, so the mitigations above must be mapped to the actual models in use. Build a short questionnaire for each vendor covering: which roles can change images, whether image changes are logged to an external collector, whether signature enforcement can be locked by policy, and how rollback works. Record the answers in your configuration baseline. Do not assume a mitigation exists on a device until the vendor documentation or a test in your environment confirms it.
Triage and response when an image change alert fires
This sequence turns a modified-image alert on a network device into a documented decision: whether the change was authorized, what differs from the known-good state, and how the device is isolated, preserved and restored. It ends with credentials rotated and evidence retained for review.
Confirm whether a change ticket exists
The on-call network or security engineer checks the change management system for an approved change covering the device, the time window and the image or firmware version named in the alert. They record the ticket number, the approver and the change owner in the incident record. The step is complete when the team can state either that a matching approved change exists or that none does. An unmatched change moves directly to the containment steps below.
Compare the running image against the known-good copy
The responder compares the running firmware or image version, its hash where the vendor exposes one, and the running configuration against the verified baseline held in version control or the backup store. Differences are listed line by line, and each is tagged as expected or unexplained. The output is a short difference report attached to the incident. Confirm the exact comparison method with the vendor's documentation, since hash and configuration export options vary by platform.
Review the administrative account and source address
The analyst pulls authentication and administrative session records for the device from the centralized log platform, such as Wazuh or Security Onion log sources, for the window around the alert. They note which account made the change, the source address and the time, and check whether that account and address were expected for the role. The step is complete when each change event has a named account, a source and an owner confirmed by the change record or the administrator.
Isolate the device if tampering is plausible
If the change is unauthorized, or the comparison shows unexplained differences, the responder restricts the device's management access and isolates it from production traffic using the change path the operations team has approved in advance. Network and security teams confirm that the device is still reachable for forensic collection from a controlled management segment. The step is complete when traffic flows and management sessions are verified against the isolation design, and the change is logged with the time it took effect.
Preserve logs, images and configuration for forensics
Before any restore, the team exports the current firmware or image, the running configuration, relevant logs and the device's management and audit records to write-once or access-controlled storage, and records a hash for each artifact. Chain-of-custody notes name who collected each item and when. The output is an evidence set that the incident lead can hand to forensic analysts or counsel. Vendor-specific collection commands and log formats must follow the device vendor's documentation.
Restore from a verified source
Once the evidence set is secured, the engineer restores the device from a known-good image or configuration whose integrity was verified before the incident, not from the possibly altered copy on the device. They apply the restore procedure from the vendor's documentation, then re-run the baseline comparison from the earlier step. The step is complete when the device matches the verified baseline and the difference report shows no unexplained items.
Rotate affected credentials and validate recovery
The team rotates the administrative credentials, API keys and any shared secrets that the affected account or device could reach, and reviews the privileged account inventory for the same exposure. They confirm multi-factor enforcement on administrative access where the platform supports it, then monitor the device for recurrence of the image-change alert. The incident closes when rotation is confirmed in the secrets system, monitoring shows no new unexplained changes, and the lessons learned are recorded for the detection rule and the change process.
Rehearsing T1601 detection in a private cyber range
A private range for T1601 needs a small set of network devices or virtual appliances that can represent the target estate, a syslog collector that receives their logs, a detection stack such as Wazuh or Security Onion, and a configuration baseline store that holds known-good images and configuration hashes. The range should be isolated from production networks and from the internet, and every device should be reachable only from the range management segment. Keep the baseline store read-only to the exercise team so that the rehearsal can prove whether the detection logic compares against a trusted reference.
- Device set: Use virtual network devices or appliances from the same platform families the organization runs in production, with at least one primary and one standby unit so that failover-related changes can be tested.
- Syslog collector: Confirm that every device forwards its management and change logs to the collector with consistent time sources, because attribution depends on accurate timestamps.
- Detection stack: Load Wazuh or Security Onion rules that map to the Command Execution and File Modification telemetry for the devices, and record the ATT&CK version used.
- Baseline store: Keep signed images and configuration hashes for each device role, with a documented owner and a rebuild procedure.
- Access control: Limit administrative accounts for the range to named testers, and confirm multi-factor authentication is enforced on the management plane.
Confirm with your device vendor which image verification and logging features the chosen platform supports before you finalize the range design.
The inject schedule defines what the red team or exercise lead changes, when, and under which conditions the blue team is allowed to see the change. Injects should be staged in increasing difficulty so that the team first confirms basic visibility, then tests attribution and finally tests whether a change that mimics a legitimate maintenance window is still flagged. Each inject should have a written expected outcome, so the debrief compares observed results with what the rules were designed to catch rather than with memory.
- Baseline inject: Apply a known, approved image change through the normal change process, and confirm the detection stack records it with the correct change ticket reference.
- Unapproved inject: Replace an image or firmware package on one device without a ticket, and record the exact time of the change for later comparison.
- Masked inject: Make the same change during a scheduled maintenance window to test whether the team treats an uncorrelated change as suspicious even when timing looks normal.
- Multi-device inject: Change images on two devices within the same window to test whether alerts keep device identity separate.
- Recovery inject: Restore a device from the baseline store to test the restoration steps and the evidence captured during rollback.
Illustrative example: a planner might schedule the unapproved inject early in the day so the team has time to triage before the end-of-day review. Agree the schedule, timings and stop conditions in writing before the exercise starts.
Good detection for T1601 means the stack raises an alert within the window agreed before the exercise and names the correct device. The alert should identify the device by hostname and management address, the change type, the time of the event and the source account. A detection that fires but attributes the event to the wrong device, or to a shared service account with no owner, does not meet the criterion. Measure detection against the expected outcome for each inject rather than against a general sense that the alert was useful.
- Alert window: Set the window in writing before the exercise, and measure the elapsed time from the inject timestamp to the first alert that carries the correct device identity.
- Attribution accuracy: Check that the alert names the affected device, the account and the originating management session, and that the device identity matches the syslog record.
- Signal quality: Record whether the approved inject raised an alert, because noise from authorized changes affects how analysts trust the stack.
- Coverage: Confirm that both the Command Execution and File Modification signals were available for each device, and note any gap in logs.
- Rule versioning: Record the detection rule version and the ATT&CK version the rule targets, so results can be compared after rules change.
Confirm with the detection engineering owner which rule versions were loaded and whether the window matches the production service level.
Good response means the analyst correlates the alert with a change ticket or confirms there is none, isolates the affected device in line with the playbook, and restores the device to a verified baseline with evidence retained. Response is scored on sequence and documentation as well as speed. Analysts should not restore a device before preserving the logs and the modified image needed for review, and they should not treat a restoration as closure until the baseline hash matches.
- Ticket correlation: Show that the analyst searched the change system for a matching ticket within the agreed period and recorded the result, including a clear no-match outcome.
- Isolation: Remove the device from production traffic or the management path according to the playbook, and document who approved the action.
- Evidence preservation: Export the relevant logs and capture the altered image or configuration hash before any rollback begins.
- Restoration: Reimage or restore the device from the baseline store, then verify the hash against the reference value and confirm that detection stops alerting on the restored state.
- Communication: Record the notifications to the change owner, the service owner and, where the playbook requires it, the incident lead.
Check with the incident response lead which approvals are needed for isolation in production-like environments before the debrief.
Questions detection engineers ask about T1601
How do I baseline image hashes on network devices that cannot hash their own images?
Start by recording a known-good baseline for each device model and software version, then compare later observations against it. Where the device cannot report a hash of its own image, take the expected value from the vendor's published checksum, or from an image you verified offline before deployment, and store it in your configuration management database. After each approved upgrade, capture the new version string, file size and checksum from your management host or from the vendor's management interface, and log it through change control. Schedule regular collection of running version information so drift from the approved baseline raises an alert. Confirm with each vendor which integrity checks their platform supports, because capability differs by model and release.
How should I handle vendor-signed upgrade events without flooding the SOC with alerts?
Treat a vendor-signed upgrade as a change, not as an anomaly, and correlate it with an approved change record before it reaches an analyst queue. Feed approved change windows, expected device names and target versions into your SIEM as an allow list, so the detection only fires when an image change occurs outside a window or targets an unexpected version. Keep the allow list under the same access controls as your detection rules, because an attacker who can edit the list can hide a change. Verify each signed upgrade after installation by comparing the running version and checksum with the vendor's published values. Review the allow list after every change cycle to remove stale entries.
Why does T1601 sit under Defense Impairment in ATT&CK v19 and later?
ATT&CK v19, released April 28, 2026, split the Enterprise Defense Evasion tactic into two tactics: Stealth, which keeps ID TA0005, and Defense Impairment, a new tactic with ID TA0112. ATT&CK defines Defense Impairment as adversaries trying to break security mechanisms, pipelines and tooling so defenders can't see or trust what is happening. Modifying a system image undermines trust in the device itself, including the software that logs, enforces policy and reports status, so it falls within that definition. If your dashboards, reports or control mappings still group this technique under Defense Evasion, update them to reflect the new tactic and confirm the mapping against the version you target.
How do I map detections to a specific ATT&CK version?
Name the ATT&CK version in every detection record, rule header and coverage report, then keep that version fixed until you deliberately migrate. MITRE's releases can rename, deprecate or revoke techniques and sub-techniques, and the detection strategies and data components referenced by a technique can change between versions. The ATT&CK version history is published on the updates page, so check it for each release you adopt. Store your mapping as data, with fields for technique ID, sub-technique ID, data component and version, so a migration becomes a reviewed diff rather than a rewrite. Re-test affected detections in your cyber range after each migration, because a renamed or split technique can leave a rule covering the wrong behavior.
What telemetry can a network device realistically send to a SIEM?
The answer depends on the vendor, the model and the license tier, so confirm it device by device before you design detections. Most platforms can export syslog for configuration changes, authentication events and administrative sessions, and many can send SNMP traps or flow records. Command logging is often limited to privileged sessions and may require AAA accounting to be enabled. Some platforms expose software version or integrity status through an API that you can poll on a schedule, while others only report it in logs at boot or upgrade. Document what each device sends, at what frequency, and whether timestamps are synchronized, because a detection built on fields a device does not emit will never fire.
How do I confirm sub-technique coverage for T1601?
Check each sub-technique individually against your telemetry, rather than assuming the parent technique coverage extends to both children. T1601 has two sub-techniques, so list each one with its ID and the detection logic you have written for it, then record the log source, data component and version that supports it. The authoritative definitions are in the enterprise-attack 20.0 STIX bundle, which you can use to pull exact names and relationships into your coverage tracker. For each sub-technique, run a controlled test in a private cyber range and record whether the alert fired, how long it took and which fields were available. A sub-technique with no successful test is a gap, not coverage.
Should we build this detection ourselves or bring in outside help?
Decide based on your device inventory, your log pipeline and the staff you can spare for ongoing tuning. The main drivers are the number of device models, whether logs from those devices already reach a central platform, whether privileged account management and multi-factor authentication are in place for device administration, and how often your vendors release upgrades. DeployOpen plans, implements and tests open-source detection and cyber range exercises under a fixed scope agreed in writing before work starts, and ongoing tuning can be covered by a retainer. DeployOpen does not issue audit reports or certifications. Ask any provider for a written scope listing devices, data sources, detection logic, test cases and deliverables, and confirm who owns the rules and evidence after handover.
Keeping T1601 mappings current across ATT&CK releases
Every T1601 mapping on this page targets Enterprise ATT&CK version 20.0, and that version should be recorded next to any detection rule, Wazuh decoder, Security Onion correlation or cyber range scenario that depends on it. ATT&CK v18, released October 28, 2025, replaced the detections in technique pages with detection strategies and analytics identified by DET IDs, and it made major updates to data components and deprecated some data sources. A detection that cites a technique ID without a version can quietly drift from what the knowledge base now says. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, so a mapping written against one of them may need review by the time it is read against the next.
For T1601 specifically, the items to recheck at each release are the technique name and its Network Devices platform scope, the list of sub-techniques under it, the data components referenced for Command Execution and File Modification, and the mitigations Privileged Account Management and Multi-factor Authentication. Releases can rename, deprecate or revoke techniques, so a sub-technique that exists today may not exist in a later bundle. The authoritative check is the enterprise-attack bundle for the target version in the mitre-attack/attack-stix-data repository, which MITRE publishes in STIX 2.1 format. Diff the new bundle against the version pinned on this page, then confirm each affected rule and range scenario still points at the right object.
Ask your DeployOpen team or your own detection engineers to record the ATT&CK version, the bundle file name and the review date in the rule metadata for every T1601 detection. Confirm with your network device vendors which log sources and command audit settings they provide, because ATT&CK's data components do not tell you whether a given router or firewall logs configuration and image changes. Plan a recheck at each new ATT&CK release and after any major firmware or operating system upgrade on your network devices, and treat a changed or deprecated object as a trigger to re-run the cyber range validation before trusting the detection again.
