Wiring the audit feed into your SIEM

The audit feed is the out-of-band way a security information and event management system (a SIEM) collects the engine’s audit trail continuously. The alternative is a human downloading an export by hand. An Owner mints a scoped audit-feed credential, and your collector presents it on every poll. The engine returns the next batch of hash-chained events along with the chain head, so the collector can checkpoint and confirm nothing went missing.

This page is for an auditor or a detection engineer who is standing up the pull. It covers the route, the cursor, the chain head, and what the events contain. The audit log concept page describes the chain itself and the on-screen export; this page covers the feed.

One fact sets the reader’s expectations first. The feed is redaction-safe for your customer data, and it deliberately carries operator and admin identity, including member emails and source IPs. The section on what the feed carries sets this out: the feed holds personal identifiers on purpose, so it is handled as a record that contains them.

Pull or push

Two mainstream methods exist for getting an audit trail into a SIEM, and downpipes supports both, so the choice is which one suits your SIEM rather than which one the platform happens to offer.

Pull, the rest of this page, suits a SIEM already polling a REST endpoint: Microsoft Sentinel, Exabeam, Cribl and Sumo Logic all take it cleanly. Pull uses a single feed credential you mint and revoke yourself rather than a stored secret. Its one friction is the Access perimeter described below: when Cloudflare Access fronts your console hostname, you add a service token or a narrow path exemption for the collector.

Push suits a SIEM that would rather be delivered to than poll, and it is not only an HTTP shape. The engine ships eight body formats over three sinks: an HTTPS endpoint, an S3 bucket your SIEM already reads, or a syslog TLS listener. Splunk, CrowdStrike and Datadog take the HTTPS sink; QRadar and LogRhythm take CEF or LEEF over syslog TLS, which their built-in parsers require and a plain HTTPS POST does not satisfy; Wazuh takes NDJSON batches dropped into a bucket. Because the engine is the one dialling out, a Cloudflare Access perimeter on the console hostname never sees an inbound request to turn away, so there is no exemption to add at all. Read forwarding the audit log to your SIEM (push) for the eight formats, the three sinks that carry them, the security posture, and the at-least-once delivery semantics.

Choose pull when your SIEM already polls and adding one Access exemption is a small cost. Choose push when your SIEM prefers HTTP intake, or you would rather not carve any exemption into your Access perimeter. Running both at once is fine too.

The audit-feed credential

The feed is served from GET /support/audit-feed, which lives outside the /admin API. A collector presents only a bearer credential: no console seat, no Cloudflare Access seat, and no admin token (handleSupportPull, engine/src/admin/support-ingest.ts). That is what lets a headless collector poll on a schedule without an interactive sign-in. Needing no Access seat does not mean an Access-fronted hostname lets the poll through, though: when Cloudflare Access fronts the console domain, the edge blocks the collector before the engine can answer, and that interaction has its own section below.

An Owner mints the credential the same way as the vendor diagnostics credential and the Prometheus metrics credential: minted once, shown once, and stored as a SHA-384 hash of the secret rather than the secret itself. All three scopes share the one mechanism (mintIngestCredential, engine/src/admin/support-ingest.ts), each capped to a lifetime suited to its job. The audit-feed scope is long-lived, because a collector polls for as long as it runs, though it is not the longest-lived of the three: the metrics scope, covered in Prometheus metrics, runs longer again. The diagnostics scope, by contrast, is short-lived for a single support ticket.

Minting asks you to re-authenticate with your passkey at the moment you do it. The mint route sits in the engine’s step-up set, so a console session cookie on its own does not reach it, and the requirement is enforced on the route rather than raised as a console prompt you could skip (STEPUP_SUBS, engine/src/admin/router-core.ts). Two callers are exempt and it is worth knowing which before you script a collector’s provisioning: the break-glass bearer token and a caller arriving through Cloudflare Access are both let past, because each carries its own possession check already (requireStepUp, engine/src/admin/router-core.ts). Dual control is a separate gate, it is opt-in, and it does not stand in for this one.

The lifetimes are enforced server-side. The engine clamps a requested time to live between a 60-second floor and the scope cap, then stamps the expiry onto the grant (INGEST_TTL_CAPS_SECONDS and the clamp in mintIngestCredential, engine/src/admin/support-ingest.ts). So even an un-revoked feed credential ages out on the engine’s own clock, and the cap means it cannot be minted beyond a year.

From console 0.2.7, each scope in the console has an Expires after (days, optional) field above its mint button. Type a whole number of days, from 1 to the scope’s maximum in the table above. If you leave it blank, the engine uses the default. The console refuses a number above the maximum before it mints, so the engine clamp never shortens a term that you chose.

When dual control is on, the first mint does not make a credential. It makes an approval request for a second Owner, and that approval applies to the scope and the term together (ownerActionGate in engine/src/admin/router-status.ts). From engine 0.3.6, the request summary shows the term, so the approver sees it. After the approval, the Owner who made the request mints again with the same term. The console keeps the number in the field for this, and tells you to mint again. If you mint with a different term, the engine does not use the approval and makes a new request.

The credential is presented as a single opaque bearer, because that is the one field every collector’s configuration form accepts.

GET /support/audit-feed?afterSeq=4096&limit=500 HTTP/1.1
Host: console.example.com
Authorization: Bearer dpc_AbCdEfGhI.dps_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

A wrong or absent bearer is a plain 401 with no detail, and verification is a constant-time comparison of the presented secret’s hash against the stored hash with server-side expiry, so a failed presentation leaks nothing about which part was wrong (checkIngestCredential, engine/src/admin/support-ingest.ts). The secret carries 192 bits of entropy, so brute force is not a realistic path.

If Cloudflare Access fronts the hostname

In the default topology the feed rides the console’s public hostname, because /support/* is proxied through the console to the routeless engine (topology). So when a Cloudflare Access application fronts that hostname, the edge turns a collector’s poll away before the engine ever sees it: Access answers with a 302 redirect to your team’s login page, whatever bearer the collector carries. The collector-side symptom is unmistakable, an HTML redirect where JSON was expected, and not a 401 from the engine. The console warns you about this at mint time when the engine detects the perimeter: the engine reports whether the mint-screen read itself arrived carrying the edge-injected cf-access-jwt-assertion header (the accessPerimeter flag on GET /admin/support, engine/src/admin/router-status.ts; the warning copy in console/src/screens/settings/support.ts).

Three arrangements let a collector through, and each keeps the feed credential as the engine-side gate.

1. Give the collector an Access service token (recommended)

   Create a separate Access application scoped to the feed path (for example console.example.com/support/audit-feed) with a Service Auth policy, and issue an Access service token. The collector sends two extra headers on every poll, CF-Access-Client-Id and CF-Access-Client-Secret, alongside the feed bearer. Access authenticates and logs the machine caller, and the more specific application takes precedence over the identity policies on the rest of the hostname. Collectors with a generic REST poller that can set custom headers handle this directly: Exabeam’s REST API collector, Cribl’s REST collector, Google Security Operations feeds and QRadar’s Universal Cloud REST API workflow all take arbitrary request headers. Microsoft Sentinel is the exception; read the callout below before using this step for Sentinel.

2. Or exempt the path with a narrow Bypass

   If your collector cannot send extra headers, give the same path-scoped application a Bypass policy instead. Access then stops gating that one path entirely and stops logging it, and the feed’s own credential is the sole gate, which is the surface’s designed posture: a 192-bit secret, constant-time verification, and a plain 401 on failure. Cloudflare’s own guidance is to prefer Service Auth over Bypass for automated traffic and to scope a Bypass as narrowly as possible, so reserve this for collectors that cannot present the token.

3. Or give the engine its own hostname

   The split topology puts the engine’s /support/* on a separate hostname with its own Access policy, so the collector’s path never crosses the console’s perimeter at all. That is the exception, not the normal case; it is described with the topology (the split variant).

Polling mechanics: cursor by sequence, carry the head

Each poll returns events in ascending sequence order, only those above your cursor, bounded by your limit, together with the chain head. The collector advances its cursor with the nextAfterSeq the engine returns and polls again.

{
  "kind": "downpipe-audit-feed",
  "v": 1,
  "afterSeq": 4096,
  "nextAfterSeq": 4220,
  "earliestSeq": 1204,
  "gapBefore": false,
  "headSeq": 4220,
  "headHash": "sha384:9f3c...e1",
  "count": 124,
  "events": [
    {
      "seq": 4097,
      "ts": "2026-06-19T02:14:08.221Z",
      "actorSubject": "https://acme.cloudflareaccess.com|01J9Z7M3QF8K2WX4P6R0V5T1AB",
      "actorEmail": "ops@acme.example",
      "actorMethod": "access",
      "sourceIp": "203.0.113.7",
      "action": "restore-approve",
      "outcome": "success",
      "target": {
        "kind": "restore",
        "runId": "run_01H...",
        "redirectBinding": null,
        "planHash": "sha384:7a2b...c4",
        "isLatest": true,
        "approverEmail": "lead@acme.example"
      },
      "prevHash": "sha384:11ab...90",
      "hash": "sha384:22cd...01"
    }
  ]
}

The checkpoint discipline follows directly. Persist nextAfterSeq after each successful batch and send it as the next afterSeq, so a restart resumes exactly where it stopped with no duplicates and nothing re-read. When count is zero the cursor does not move and headSeq tells you that you are caught up. When headSeq is far above your cursor you are behind and the next polls will catch up in batches of up to limit. Send the cursor as a plain non-negative integer: a present but malformed afterSeq is a 400 rather than a silent reset to 0, so a collector persisting a corrupt checkpoint fails loudly instead of replaying the whole retained log forever (handleSupportPull, engine/src/admin/support-ingest.ts).

Verifying continuity from the feed

The feed is not only a stream of events, it is a stream you can prove is unbroken. Each event carries prevHash and hash, both sha384: digests. Each hash is computed over the canonical form of every field of the entry except the hash itself, including the prevHash. So each entry commits to its own content and to the prior entry’s hash. The chain is linked with SHA-384 throughout (auditHash, engine/src/admin/audit.ts).

A collector verifies continuity with two local checks as it ingests.

1. Link each entry to the one before it

   For two consecutive events, the later event’s prevHash must equal the earlier event’s hash. A mismatch means an entry was inserted, removed, reordered, or its predecessor was edited. Across a poll boundary the same rule holds: the first event of a new batch must link to the last event of the previous batch.

2. Check the sequence is contiguous

   Each event’s seq must be exactly one greater than the previous event’s seq. A gap means an entry between them is missing, even if a sophisticated tamper re-linked the hashes around the hole. This is why the verifier checks the sequence as well as the hash link.

3. Pin the head out of band

   Store headHash from your most recent poll somewhere the engine cannot reach. Later you can recompute the chain over what you ingested and confirm it ends at the same head, which is how truncation after a poll becomes detectable rather than silent.

4. Watch the retention floor

   The two checks above cover the events you received. gapBefore covers the ones you did not: it is true when retention rolled entries off between your cursor and the oldest sequence still held, which no link or sequence check on the delivered batch can see, because the missing entries were never in a batch. Alert on it as a delivery failure, not as an anomaly in the chain.

This is the tamper-evident property in operational terms: alteration is detectable, it is not prevented. A holder of the underlying storage could rewrite the entire chain from a forged start, recomputing every hash, and that fully re-chained log would still verify on its own. What the chain guarantees is narrower. Any edit or deletion of a past entry that is not a full re-chain breaks one of the two checks above. The head hash you pinned lets you detect truncation that happened after you read it.

What the feed carries, and what it does not

The events are redaction-safe for your customer data. The recorder accepts only a small closed set of target shapes and has no free-form field a caller could stuff a value into, so the trail can never hold a key, a secret value, a private fingerprint, or a destination’s credential, endpoint, bucket or region (AuditTarget and the redaction-by-construction note in engine/src/admin/audit.ts). The feed carries no customer backup data, no keys and no secrets.

What the feed does carry is operator and admin identity, on purpose, because attributability is the point of an audit trail.

On the wire, target is always a small structured object keyed by kind, as in the example above, never a flat string. The table below shows describeTarget()’s one-line rendering of the same structured target, the form used in the CSV export and the console summary (engine/src/admin/audit.ts), so you can recognise the identity a given kind carries either way.

The feed is read-only. The route is a GET that returns events and the chain head. There is no write path here that could expose customer data or mutate anything (handleSupportPull, engine/src/admin/support-ingest.ts). A collector consumes the feed; it cannot drive the engine through it.

The lease is revocable, and its expiry is tracked

The audit-feed credential is a per-grant lease, not a standing vendor-held key, and it is revocable at any moment. Revoking it is immediate: the next poll the collector attempts returns 401 as soon as you confirm, and only one credential is active per scope, so re-minting replaces the prior grant and kills the prior secret. There is no edit of the same secret, so rotation means revoke and re-mint.

The revoke asks for no step-up, deliberately and unlike the mint. Demanding a fresh re-authentication before you can shut off a credential you believe is stolen would be friction at the worst possible moment, so the gate is on the direction that opens the surface rather than the one that closes it. Rotation therefore meets the step-up on the re-mint, not on the revoke. A collector’s credential can always be killed with whatever session you already have.

The engine keeps a customer-visible usage trail on the grant: the most recent 50 polls are recorded by timestamp, with older entries rolling over, so you can see when the credential was last used (IngestGrant.pulls and the pull recording in handleSupportPull, engine/src/admin/support-ingest.ts). The recording is best-effort and never blocks a poll.

The credential’s expiry is also auto-observed in the credential lifecycle registry, so it appears in your single view of every expiring credential. The audit-feed bearer is registered as a functional credential, identified by its public client id only. The bearer’s row is dropped automatically when you revoke the grant (upsertObservedItem for the ingest-audit-feed item, engine/src/sched/scheduler-do.ts). The secret and its hash are never written there, exactly as they are never written to the trail.

Microsoft Sentinel

For Microsoft Sentinel, deploy the Codeless connector from the standalone ARM template under integrations/microsoft-sentinel/ in the engine repo. Microsoft Sentinel walks through the deploy.

Where this fits

This page covers the feed mechanics. The chain itself, the on-screen verify, and the manual JSON or CSV export are described in the audit log: hash-chained, redaction-safe, and how to verify, export and feed your SIEM, which links here for the SIEM detail.

For the other scope of the same minting mechanism, the short-lived vendor diagnostics credential, read owner-minted pull credentials. To see every minted credential’s expiry in one place, including this feed’s, read the credential lifecycle registry.

Last updated 25 September 2026.