What is the difference between centralised logging and federated investigation?

How the two approaches differ in practice

Centralised logging and federated investigation solve related but different problems. Centralised logging is about log management and retention: moving events into one place so teams can index, retain, search, alert and review them consistently. Federated investigation keeps the data close to the source and asks multiple systems for the evidence needed to answer a question.

The practical difference is where the work happens. Centralisation favours one storage and analytics layer, which is easier to standardise and govern. Federation favours the original telemetry owners, which can preserve source-specific fields, reduce duplication and avoid building a second logging pipeline for every platform.

That means the two patterns also differ in operational burden. Centralised logging shifts effort toward ingestion, normalisation, storage cost and query performance. Federated investigation shifts effort toward query orchestration, source permissions, schema alignment and ensuring the investigator can correlate results across cloud, endpoint and application telemetry.

What each model is best at

Centralised logging is strongest when the main goal is durable retention, broad search, common alerting and a single place to prove that logs were collected. It is often the cleaner choice when a team needs a unified archive, standard dashboards or one review workflow across many systems.

Federated investigation is strongest when the main goal is to preserve context and inspect telemetry where it naturally lives. That matters when a platform already has rich local logs, when moving everything centrally would be too expensive, or when the investigative question spans distributed services that do not fit neatly into one repository.

In identity and access work, the distinction is often most visible in investigations. A central log lake helps with repeatable review, but a federated approach can be better when you need to compare sign-in, workload, cloud and application signals without losing the original source detail. For that reason, teams often pair both models rather than choosing one absolutely.

What usually breaks the design

The most common failure is treating centralisation as if it automatically equals visibility. If collection is incomplete, delayed or poorly normalised, a central repository can still miss the evidence that matters. In those cases, the issue is not the storage model, it is the telemetry quality and coverage.

Federated investigation can fail in the opposite way: if access controls, query tooling or field naming are inconsistent, investigators get a fragmented view and spend time reconciling results instead of testing hypotheses. The model only works when source systems expose enough structured telemetry for correlation and when teams agree on a minimum investigative schema.

Risk and Threat Considerations

The main security trade-off is between concentration and distribution. Centralised logging creates a high-value target and a single operational dependency, while federated investigation can leave gaps if teams cannot search across sources quickly enough during an incident.

Failure mechanism: Centralisation can fail through ingestion gaps, delayed forwarding, log tampering before export, or cost-driven truncation; federation can fail when investigators lack permissions, consistent fields, or a reliable way to correlate events across systems.

Impact: Either failure mode can slow detection, weaken forensic confidence, and hide attacker activity long enough for persistence, lateral movement, or credential abuse to continue.

Practitioner Guidance

What to verify: Decide whether your primary need is evidence retention, rapid cross-source investigation, or both. If retention is the priority, validate ingestion completeness, time synchronisation and retention policy. If investigation is the priority, validate that the source systems expose the fields you need for correlation, including actor, target, time and session markers.

Decision rule: Use centralised logging when you need one durable evidence store and one alerting plane; use federated investigation when source context is too important to flatten, or when full duplication would be expensive or slow. In mature environments, keep centralised logs for baseline visibility and use federation for deeper questions that need original context.

Practitioner takeaway: The right answer is rarely “centralised or federated” in isolation, it is deciding which telemetry must be duplicated for control and which should stay in place for context, cost and investigative fidelity.

Related resources from NHI Mgmt Group

• What should teams verify in logging before they call it investigation-ready?
• What breaks when AI logging is not centralised?
• What breaks when firewall logging and retention are too limited to support investigation after a breach?
• How should SOC teams design logging pipelines for investigation and forensics?