Compromised camera software let attackers in because *the logs were missing*

A breach without a trail

Someone broke into a corporate network through camera management software, and the security team knew that much within hours. What they could not work out was which camera application had been compromised, how the attackers got in or whether the same weakness existed on other systems.

The reason was simple: no logs ^[1].

Without logs, there is no forensic trail. You can see that something happened, but not what, when or how. It is like finding a broken window and no footprints.

The camera software that let the attackers in was managing devices across the network, and the breach gave them a foothold. But because the software kept no record of what it did or who connected to it, the investigation stopped there. The entry point was known, the method was not, and that gap meant the team could not rule out the same vulnerability being present in other parts of the estate.

Why cameras are a way in

Camera systems sit on corporate networks, often with broad access, and the software that manages them can be a tempting target. If an attacker compromises the management application, they get a step inside the perimeter without having to touch email or endpoints that are more closely watched.

In this case, the analysts knew cameras were involved and suspected the management software, but they could not confirm which product it was ^[1]. That matters, because without knowing the application, you cannot patch it, replace it or even warn others running the same thing.

The lack of logging turned a technical breach into a dead end.

What logging would have shown

Logs are the receipts of what a system does: who connected, when, what commands were sent and what the software did in response. In a breach investigation, those receipts let you trace the attack backwards.

If the camera software had logged connections and actions, the analysts could have seen which account or IP address was used, at what time the compromise happened and what the attacker did once inside. From there, they could have checked whether the same access pattern appeared elsewhere, whether credentials were reused and whether the vulnerability had been patched.

Without logs, none of that is possible. You are left knowing that a breach happened, but not how to prevent it happening again.

The Cyber Resilience Act and logging

From 11 December 2027, products with digital elements placed on the EU market must meet essential cybersecurity requirements under the Cyber Resilience Act ^[2]. One of those requirements, in Annex I, is that a product must be able to log and monitor security-relevant events.

The regulation does not say how those logs must be protected, only that the product must be capable of producing them. That is a start, but it leaves a gap: a log that can be quietly edited is easier to challenge when someone asks what happened.

Say the camera software in this case had logged every connection. If the attacker, or someone with administrator access to the logging system, could delete or alter those entries, the investigation would still hit a wall. The logs might exist in principle, but if they cannot be trusted, they do not help.

Logs you can trust

A log its keeper can change is a diary. A log that shows when it has been changed is evidence.

Here, the thing to seal is log segments at short intervals, for example every few minutes. Sealing takes a fingerprint of the segment, not the data itself, so the log never leaves your systems. If the log is questioned months later, anyone you share it with can check that it is the one written at the time.

The fingerprint is sealed on WitniumChain, where any later change would show, even one made by us. To check, you calculate the fingerprint again. If it matches, nothing has changed. Change a single character in the log and it will not match.

What it shows is that a log segment has not been altered since it was sealed, even by someone with administrator rights. What it does not do is replace access control, monitoring or backups. Those still matter. A sealed log tells you whether it has changed; it does not tell you whether it was complete or accurate in the first place.

You can seal logs continuously through the REST API, the SDK or the MCP server docs. Your system sends a fingerprint of each segment as it closes, gets a witness ID back and stores that alongside the log. The first 2,000 witnesses a month are free.

How it would work

1. Each log segment is fingerprinted as it closes, for example every five minutes.
2. The fingerprint is sealed, and the witness ID is stored with the segment.
3. When an incident is investigated, the log is shared and anyone can check that it matches the sealed fingerprint.

What this means for you

If you make or run software that sits on a network and manages devices, ask:

• Does the software log connections, commands and errors?
• Can those logs be turned on by default, or do they require manual configuration that often gets skipped?
• If a breach happened today, would the logs show you what the attacker did and when?
• Can someone with administrator access edit or delete log entries without that change being visible?

If the answer to the last question is yes, the logs exist but they are easy to challenge. Sealing them as they are written gives you a record that holds up when questioned.

For manufacturers placing products on the EU market, the Cyber Resilience Act's logging requirement applies from 11 December 2027. Start now, because retrofitting logging into a deployed product is harder than building it in.

What to watch

• 11 December 2027: Essential cybersecurity requirements under the Cyber Resilience Act apply to products with digital elements placed on the EU market ^[2].
• 11 September 2026: Reporting obligations for actively exploited vulnerabilities and severe incidents take effect, with a 24-hour early warning deadline ^[3].