Notifications
Clear all
Topic starter
18/08/2026 2:23 pm
TL;DR: Log pipelines now need destination-aware control, not Splunk-only formatting, according to Axoflow. Its analysis argues that SC4S works well as a Splunk connector but breaks down when teams need multi-destination routing, per-destination normalization, and lower SIEM ingestion costs, with 40-70% data reduction before ingestion.
NHIMG editorial — based on content published by Axoflow: SC4S alternative and multi-destination log routing without vendor lock-in
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams design log pipelines for multiple destinations?
A: Use a destination-aware pipeline that normalizes events for each consumer rather than forcing one generic format everywhere.
Q: Why do Splunk-centric routing models become a problem as programmes mature?
A: They bake one consumer's schema and routing assumptions into the collection layer, which makes multi-tool analytics, migration, and storage optimisation harder later.
Q: What do security teams get wrong about log normalization?
A: They often treat normalization as formatting work instead of a detection requirement.
Practitioner guidance
- Define destination-specific normalization rules Map the required field structure for each destination, including SIEM, data lake, and detection tooling, and verify that host and source metadata remain intact across all paths.
- Separate high-value telemetry from compliance-only logs Route security-relevant events to search and detection platforms, and send low-urgency retention data to cheaper object storage so the SIEM only carries data that supports investigation.
- Inventory parser dependencies before changing pipelines Document which device definitions, classification rules, and custom parsers are holding the current ingest design together so that a migration does not recreate hidden brittle dependencies.
What's in the full article
Axoflow's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step comparison of SC4S routing assumptions versus multi-destination pipeline behaviour
- Specific examples of per-destination formatting for Splunk, Microsoft Sentinel, data lakes, and object storage
- Operational detail on parser coverage, maintenance, and deployment trade-offs
- Cost-reduction mechanics behind shifting low-urgency data away from premium SIEM storage
👉 Read Axoflow's analysis of SC4S limits and multi-destination log routing →
SC4S vs multi-destination pipelines: what changes for security teams?
Explore further
18/08/2026 3:14 pm
Destination-aware log pipelines are now a control plane, not a transport utility. Once a collection layer decides whether data goes to a SIEM, a data lake, or long-term storage, it is shaping investigation quality, cost, and retention policy at the same time. In identity-heavy environments, that affects auditability for service accounts, privileged sessions, and API activity. Teams should treat the pipeline as governed security infrastructure, not a convenience layer.
A question worth separating out:
Q: How can teams decide whether to keep more logs in the SIEM or move them elsewhere?
A: Base the decision on investigative value, detection use cases, and retention requirements, not on habit. If events are searched rarely but retained for policy reasons, move them to lower-cost storage and keep only the telemetry that actively supports alerting, correlation, or identity investigations in the SIEM.
👉 Read our full editorial: Multi-destination log routing reshapes SIEM cost and data control
