Keep logs at the edge when the data is only needed for short-lived troubleshooting, local maintenance, or narrow operational checks. Centralising everything adds cost and latency without improving security value if no broader correlation is required. The decision should follow the use case, retention need, and who must query the data.
When edge logging is the better fit
Edge logging makes sense when the event data is only useful close to the system that produced it, for example for short troubleshooting windows, local maintenance, or a narrow operational check. If the logs do not need enterprise-wide correlation, forwarding every record to a central platform often adds latency, storage cost, and noise without improving security outcomes.
The practical question is whether the value of central analysis exceeds the overhead of transporting, normalising, and retaining the data. If the answer is no, keeping logs near the workload can preserve faster access for operators while reducing the volume of data moved across the environment.
That choice is also shaped by locality. Some telemetry is only meaningful in context, such as a device fault, an on-site service issue, or a temporary maintenance task where the responder needs immediate access but no broader investigation is expected.
What centralisation changes, and when it is worth it
Central logging becomes valuable when teams need cross-system correlation, long retention, or independent review by another function. It supports detection logic, incident investigation, compliance retention, and trend analysis that edge-only logs cannot reliably provide on their own.
NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference point here because audit logging and log review are controls, not just storage decisions. If the organisation expects logs to support detection, response, or evidentiary needs, central retention usually becomes part of the control objective rather than an optional convenience.
NIST Cybersecurity Framework 2.0 also fits because the decision sits between detection and response outcomes. Centralisation helps when it improves visibility across assets, but it should not be treated as a default if it does not change how quickly teams can identify or contain an issue.
In practice, the strongest argument for centralising logs is not “more data is better”, but that the data must be queryable across systems at the moment it becomes operationally or legally relevant. If no one outside the local team will ever need the records, centralisation is often excess handling rather than added value.
Choosing the right log placement by use case
Edge retention is usually the better design when the data has a short shelf life, low investigative value, or a clearly bounded audience. Centralisation is the better design when the logs must outlive the device, support multiple responders, or feed detection pipelines that depend on aggregation.
NIST Privacy Framework is relevant because log placement affects minimisation and retention discipline. Keeping data local can reduce exposure when the operational need is narrow, while centralisation increases the number of systems and people that can access the same record.
EU General Data Protection Regulation (GDPR) becomes relevant whenever logs contain personal data, because the retention and access model must stay proportionate to the purpose. Even where legal compliance is not the main driver, the same principle applies: keep records where they serve the use case, and no further.
Risk and Threat Considerations
Logging architecture creates exposure in both directions. Over-centralisation can expand the blast radius of sensitive operational data, while keeping everything only at the edge can leave teams blind when they need cross-system evidence, containment context, or durable records after a failure.
Failure mechanism: The main failure mode is mismatch between log location and log purpose, either by moving unnecessary detail into a shared platform or by leaving needed evidence stranded on a device that is offline, overwritten, or unavailable when an incident occurs.
Impact: Centralised logs can increase storage, access, and privacy exposure; edge-only logs can delay investigation, weaken correlation, and make it harder to prove what happened during an incident or maintenance event.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Log placement affects what events are captured and retained for security monitoring and response. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Centralisation is justified when logs must support review, analysis, and cross-system reporting. | |
| AU-11 — Audit Record Retention | The edge-versus-central choice is driven by how long records must be kept for operational or investigative use. | |
| Recommendation — Define log sources, retention, and review requirements for each event class. Aggregate logs needed for analysis and review into a queryable platform. Set retention periods to match operational need and compliance requirements. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Logging placement determines how well teams can monitor events and anomalies across the environment. |
| RC.CO-03 — Public Updates on Incident Recovery Progress | Durable, accessible logs support coordinated recovery and accurate incident communication. | |
| Recommendation — Ensure log collection supports monitoring where correlation is required. Retain records that help reconstruct incidents and support recovery coordination. | ||
Practitioner Guidance
What to prioritise: Classify each log stream by its actual consumer and retention need before deciding where it lives. If the first user is the local operator and the record has no broader analytical value, keep it at the edge; if it supports detection, response, or audit, plan for central availability.
Decision rule: If the log is needed only for a short-lived operational task, keep it local with a defined expiry. If any other team, tool, or process must query it later, centralise only the fields required for that wider purpose and preserve the local source when it adds context.
What good looks like: The organisation can explain, for each log class, why it is local or central, how long it is retained, who can query it, and what business or security use case that choice supports.
Practitioner takeaway: The right answer is rarely “centralise everything” or “keep everything at the edge”; it is to place logs where they remain useful without creating unnecessary handling, latency, or exposure.
Related resources from NHI Mgmt Group
- What breaks when security teams keep logs in separate tools instead of building a shared telemetry layer?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?
- How should security teams govern non-human identities for compliance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org