Yes, if they still need local console or file logging for operational purposes. The key is to treat OpenTelemetry as an additional governed path, not a replacement by default. Keep only the sinks that serve a clear operational need and document why each one exists.
Why this is an observability decision, not a binary logging decision
Adding OpenTelemetry forwarding does not automatically make existing Serilog sinks obsolete. Serilog and OpenTelemetry often solve overlapping but different operational needs: one may feed centralized telemetry, while the other still supports local troubleshooting, emergency access, or legacy workflows. The right question is which sinks still carry unique operational value and which now only duplicate data.
That distinction matters because logging paths are part of the system’s control surface. The more paths you keep, the more you must govern retention, access, formatting, and failure behavior. If a sink is only present out of habit, it becomes noise rather than a resilience or diagnostics asset.
When keeping a sink still makes sense
Keep a sink when it serves a concrete use case that OpenTelemetry forwarding does not fully replace. Common examples are local console output for container platforms, file logging for break-glass troubleshooting, or a short-term fallback when upstream telemetry delivery is degraded. If a sink is the only practical way to inspect a failure on the host, it still has value.
Retention should also follow operational need. A sink that supports incident response during an outage may be justified even if most day-to-day analysis happens elsewhere. By contrast, sinks that only duplicate the same event stream into multiple destinations without improving visibility, recovery, or supportability should usually be removed.
How to decide what to remove after forwarding is enabled
Review each sink against three questions: does it add a distinct operational capability, does anyone actively depend on it, and does it create extra maintenance or exposure? If the answer to all three is no, it is a good candidate for removal. This is especially true for sinks that bypass central retention rules, expand access to log data, or make sensitive fields easier to spread.
When teams keep both Serilog and OpenTelemetry paths, they should document the purpose of each route and verify that event volume, filtering, and redaction are aligned. It is easy for dual paths to drift, with one path carrying richer data than the other or one path quietly becoming the trusted source for investigations. That creates inconsistent evidence and undermines confidence in the logging pipeline.
Risk and Threat Considerations
Multiple logging paths increase the chance of secret exposure, duplicate retention, and inconsistent monitoring if one sink is more permissive than another. They can also widen the blast radius of a compromised application, because attackers often abuse logs to find tokens, configuration values, or operational clues.
Failure mechanism: Teams keep redundant sinks without clear ownership or filtering, so sensitive events are written to more places than intended, and operational drift makes one path harder to secure than the others.
Impact: This can create unnecessary data exposure, complicate incident investigation, and leave teams with conflicting records of what the system actually emitted.
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 CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Serilog and OpenTelemetry both shape which audit events are captured and retained. |
| AU-12 — Audit Record Generation | The question is about maintaining or retiring logging paths that generate records. | |
| AU-9 — Protection of Audit Information | Multiple sinks can expand exposure if logs are written to less controlled locations. | |
| Recommendation — Define which events each sink must record and remove duplicate paths that add no audit value. Ensure each retained sink has a clear record-generation purpose and a defined destination. Protect retained log paths with access limits, integrity controls, and restricted retention. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The decision is fundamentally about which logging channels to keep and govern. |
| Recommendation — Keep only the logging channels that improve detection, troubleshooting, or investigation. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Retaining Serilog sinks after OpenTelemetry forwarding is a logging control design decision. |
| Recommendation — Document each retained sink, its purpose, and its retention and review requirements. | ||
Practitioner Guidance
What to prioritise: Keep the sink only if it supports a real troubleshooting or continuity need that OpenTelemetry forwarding does not already satisfy. If both paths remain, assign an owner for each and define which one is authoritative for operations and which one is just a fallback.
What to verify: Check that the retained sink has a stated purpose, a retention limit, and filtering or redaction controls that match the sensitivity of the events it receives. Verify that removing it would not block local diagnostics, outage recovery, or on-host support.
Common mistake: Treating OpenTelemetry as a universal replacement and leaving old sinks enabled “just in case.” That pattern usually preserves duplication without preserving accountability.
Practitioner takeaway: Keep sinks for distinct operational value, not for historical convenience, and remove any path that no longer changes how the team detects, troubleshoots, or recovers from failure.
Related resources from NHI Mgmt Group
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