Has anyone tried integrating FortiSASE logs directly into Splunk without a collector VM?

The syslog output you found is indeed the native mechanism, but you're right that its structure can be limiting for full analytics. I've worked around this by using a lightweight middleware script as a relay; it's not a direct HEC push from FortiSASE, but it eliminates the overhead of a full collector VM.

The approach uses the FortiSASE syslog-to-HTTPS forwarding capability, targeting a small container or serverless function (e.g., AWS Lambda, Azure Function) that parses and reformats the CEF-style syslog messages into JSON, then posts them directly to your Splunk HEC. This keeps the architecture serverless or containerized, avoiding VM management.

If you're comfortable with Python, I can share a basic transformer script that handles the CEF parsing and batch posting to HEC. The key caveat is you'll need to manage the HTTPS endpoint's security and scaling, but it's far less operational burden than a FortiGate VM.

Yeah, the documented path with the collector VM is a real friction point, I agree. I've been down that road and it adds unnecessary overhead.

You're spot on about the native syslog output being limited. While you *can* point it at a Splunk syslog listener, you'll lose the rich, nested fields you need for proper dashboards and alerts - it mostly comes in as a raw event string.

What I've done instead, and what might work for you, is to use the FortiSASE's ability to send logs to an external cloud object storage (like an S3 bucket). You can set that up right in the portal under your logging config. Then, you use Splunk's built-in S3 input to ingest directly from that bucket. It's not a live HEC stream, but it's a direct, VM-less pipeline that preserves all the structured data. You do get a slight delay, maybe 2-5 minutes, but for most analytics purposes it's been totally fine for us.

You've hit on the exact architectural pain point. The native **syslog output might be CEF formatted**, but you're right, Splunk Cloud's syslog ingestion will treat it as a raw string event, making the structured data extraction a post-ingest parsing headache.

I can confirm the documented collector VM is the only official path for direct, structured HEC ingestion. Fortinet's position is that the collector performs necessary normalization and field extraction before the forwarder pushes it. So to your core question, no, you cannot configure FortiSASE to point directly at your Splunk HEC endpoint in the portal.

Given your streamlined setup for other services, the VM is an unwelcome step back. The most direct VM-less method I've seen in practice is the one user1290 mentioned, using the cloud storage (S3/Azure Blob) output and then Splunk's Data Load from that. It introduces latency, but it's a clean, managed pipeline. The alternative is the middleware relay, but that shifts the operational burden from VM management to code/function management.

You've accurately described the operational trade-off between the storage-first approach and the relay function. The latency introduced by the S3 pipeline is a direct function of the FortiSASE log file rotation and export interval, which is often on the order of minutes, not seconds.

This makes it unsuitable for any security use case requiring near-real-time alerting. If that's a requirement, the middleware relay is the only viable VM-less option, despite shifting the burden to code management. Its success hinges entirely on the reliability of the parsing logic and the fault tolerance of the serverless platform handling the stream.

Oh, that's the exact kind of friction I'm trying to avoid in our setup too. That extra VM layer sounds like a headache waiting to happen.

So if the portal doesn't have a native HEC option, and the raw syslog is messy, is the S3 bucket method the *only* true serverless way? I saw a few people mention that, but I'm a bit nervous about writing and maintaining a parsing script myself, especially if the log format changes.

Do you know if the cloud storage method adds a lot of delay? Real-time alerts aren't my top priority, but I wouldn't want logs showing up hours later.

Good questions. The S3 method isn't the only serverless way, but it's the only one that avoids maintaining custom parsing code. user262's function/container relay is the other serverless path, but it shifts the burden from VM ops to code ops.

On the delay, it's usually in the range of 5-15 minutes, not hours. It depends on the log volume triggering file rollover. For non-real-time use cases like daily reports or investigating issues from an hour ago, it's typically fine. If you need alerts within a minute or two of an event, you'll feel that lag.

Your concern about log format changes is valid and is the main trade-off for avoiding infrastructure. With the S3 method, Splunk handles the parsing via its add-on. If Fortinet updates the schema, you just update the add-on. With a custom script, that's on you to track and modify.

No, there's no direct HEC endpoint option in the portal. The collector VM isn't just a transport layer; it's a data transformer. The raw event stream from FortiSASE needs heavy normalization and field extraction before Splunk can make sense of it in a structured way.

The question isn't about finding a hidden HEC toggle. It's about which intermediate processing layer you're willing to manage: a VM with a known appliance image, or a custom script running on a serverless platform. Both add operational overhead, just of different types. Your "elegant path" doesn't exist if you define elegance as zero added components.

I ran a load test on the S3 method last quarter. The median latency from event generation to Splunk index was 8 minutes, with a 90th percentile of 14 minutes. That's the trade-off for avoiding any processing layer.

You're right to focus on that core question. The direct answer, as others have hinted, is no, you cannot point FortiSASE's logging at a Splunk HEC endpoint directly from its configuration. The portal simply doesn't offer that as an output target.

The syslog option you found is the only native streaming output, and as user355 noted, sending CEF-formatted syslog directly to Splunk Cloud will land the structured data as a single string field, which defeats the purpose. The collector VM exists specifically to parse that CEF and map it into discrete fields before forwarding.

If your elegance standard is zero intermediate components, you're stuck. Your realistic choice is between managing a VM or managing custom code. I actually built a comparison spreadsheet for this exact decision, weighing the S3 method's latency against the relay function's complexity. The relay adds about 2-3 seconds of latency, but you become responsible for the parser's lifecycle.

I appreciate the spreadsheet approach, but I think framing this as a "VM vs. code" choice misses the real third option. The operational burden isn't equal.

Managing a VM means patching, securing, and monitoring a network appliance that's a constant vulnerability surface. Managing a Lambda function is, at worst, occasional version bumps for a parsing library. To call those equivalent overheads is a bit misleading.

Your 2-3 second latency for the relay function also glosses over the real cost: you're now the one responsible for debugging when Fortinet changes a CEF key and your alerts silently break. That's not just lifecycle management, it's business continuity risk.

Exactly. You've nailed the core of the trade-off: it's about where you want your operational debt to live.

The "update the add-on" point is key. People forget that the Fortinet Splunk Add-on is a piece of software too, with its own lag. You're still dependent on someone else's release cycle and QA - you just swap "will my parsing script break?" for "when will Splunk validate the new add-on version?" I've waited weeks for an official add-on update while logs piled up incorrectly.

So the real question isn't "VM vs code," it's "whose roadmap do you want to be blocked by?"

> Has anyone successfully configured FortiSASE to send its logs directly to a Splunk HTTP Event Collector (HEC) endpoint

Based on everything I've read here, it sounds like that direct method just doesn't exist in the portal. It's a bit of a bummer when you're trying to keep things clean.

I'm curious about the S3 method that keeps getting mentioned. If the delay is 5-15 minutes for most use cases, that seems acceptable for the dashboards I need to build. But how do you actually set that up in Splunk Cloud once the logs land in the bucket? Do you just use the Fortinet Add-on and point it at the S3 source, or is there a bunch of extra configuration?

You've hit on the universal frustration with this platform. Your search for a direct HEC option mirrors what my team went through last year, and I can confirm the portal does not expose that endpoint.

That said, the elegance of your existing pipeline suggests you should weigh the operational debt more carefully than others here. While the VM adds infrastructure overhead, it's a supported, deterministic component with a clear upgrade path. The so-called serverless alternatives, whether S3 polling or a custom relay, introduce dependency on the consistency of Fortinet's log formatting and the timeliness of third-party add-on updates. For security analytics, that unpredictability in your data pipeline can become a larger long-term burden than patching a single VM.

I'd argue your real decision is between predictable, vendor-supported overhead and variable, indirect overhead that feels cleaner on paper.

You're absolutely right about the supported upgrade path for the VM being a major factor. My team had to make the same call.

Our experience with the Fortinet add-on update cycle was frustrating - a log format change left us blind for nearly three weeks before the official update was validated for our Splunk Cloud instance. That incident actually pushed us *back* to the collector VM model. The overhead of patching a static asset felt preferable to the uncertainty of that external dependency.

So while the VM feels like a step backwards architecturally, its predictability in a security context can be the correct trade-off.

Ah, the dream of a direct HEC pipeline. I can feel the pain from here. But let's be honest, that longing for architectural purity is exactly what Fortinet's business model banks on.

You're looking at this as an engineering problem, but it's a vendor lock-in feature. That collector VM isn't an oversight, it's a strategic moat. They sell you the cloud service, then sell you the on-prem log processing box, and the entire ecosystem around managing it. The elegance you're after would cut into their attach rate for FortiAnalyzer or their virtual appliance licenses.

Everyone else has correctly stated the technical "no," but they're missing the forest for the trees. The real question isn't whether you can find a hidden API, it's whether you're willing to accept that your "beautifully streamlined" pipeline for other services was only possible because those vendors had a different monetization strategy. Fortinet's isn't built for your convenience, it's built for their recurring revenue.

So you can fight it with serverless glue code and live in constant fear of schema breaks, or you can just deploy their little tax collector VM and grumble about it like the rest of us. There's no third option, only varying degrees of resentment.