SIEM Export

DFNS now forwards its signed-action audit trail into your SIEM, starting with Datadog Cloud SIEM, so your SOC detects, correlates, and responds on digital asset operations the same way it does on everything else.

Harrison Tross
Harrison Tross
| 5 min read

DFNS now exports its audit trail to your SIEM. Privileged action signed on DFNS, moving funds, exporting a key, editing a user, changing a policy or an access control, arrives in your security operations center as a structured log the moment it resolves, with its outcome attached: allowed, denied, or failed. The first supported destination is Datadog Cloud SIEM, forwarded per Org, using your own API key, into the pipeline where your detection rules and triage already run.

Security teams have spent years building detection logic, correlation, and on-call around their log platform. Digital asset operations should not live outside it. Now they don’t.

The feed that matters: signed actions and their outcomes

DFNS already keeps an authoritative record of every user-signed action: the signed payload, the API path, a human-readable summary, the actor and Org, the lifecycle timestamps from signature to execution to resolution, and the outcome. SIEM Export streams that record. One log per resolved action, with the true event time from the database, and the full action nested as a facetable object your rules can query field by field.

Two properties make it a security feed rather than an activity feed.

  1. First, it includes attempts, not just successes: an action that was signed and denied by policy, or that failed, is exported with its status and error, which is precisely the signal that reveals credential misuse or an insider probing what they can get away with.
  2. Second, the keys are stable and yours to build on: source dfns, service dfns-audit, and tags carrying the event kind, the Org, and any tags you add to match your own taxonomy, env:prod, a business unit, a jurisdiction.
{
  "ddsource": "dfns",
  "service": "dfns-audit",
  "ddtags": "event_kind:user_action.resolved,orgId:or-...,env:prod",
  "message": "Transfer 250,000 USDC to 0x8f3a...",
  "date": "2026-09-02T14:07:31Z",
  "evt": {
    "kind": "user_action.resolved",
    "userId": "us-...",
    "actionPath": "/wallets/wa-.../transfers",
    "responseStatus": 403,
    "responseError": "Denied by policy",
    "dateSigned": "...", "datePerformed": "...", "dateResolved": "...",
    "action": { ... }
  }
}

Built like a security control, not a notification

An export pipeline that could slow down or fail the actions it observes would be a liability. This one cannot. Emission is bound to the single database transition that marks an action resolved, it never blocks the write, and it runs on an independent consumer with its own offsets and retry queues, so an outage at your SIEM can never affect your webhooks or your operations. Delivery is at-least-once, with retries and a dead-letter queue redrivable for roughly 18 hours, and every duplicate carries the same event ID, so count-based rules simply use a unique count. Events older than the intake window are dropped and logged rather than silently lost.

Your Datadog API key is encrypted at rest, decrypted only in memory at send time, and classified so it is never written to a log in cleartext. Custom tags are validated against Datadog’s format, so nothing can inject its way into the tag set. No new egress posture is required.

What this unlocks for your SOC

  • Detection, where your rules already live. Alert on any key export, anywhere, instantly. Flag policy changes outside your change window. Catch a spike in denied actions from one user, the fingerprint of stolen credentials or an insider testing limits. Surface a signed transfer at 3 a.m. from a user who has never operated at night, or a permission grant to a user created an hour ago. These are two-line rules in Datadog once the feed exists.
  • Correlation across your estate. A DFNS action is now one event among the rest: the same user’s identity-provider login from an unfamiliar country, an endpoint-detection alert on their laptop twenty minutes earlier, a VPN session that shouldn’t be there. Digital asset operations stop being a silo your SOC squints at through a separate dashboard.
  • Incident timelines with the truth in them. When something goes wrong, the export gives you the full lifecycle of every action, signed, performed, resolved, with true timestamps and outcomes, in the platform your incident responders already know, alongside every other system’s logs.
  • Evidence, retained on your terms. Regulators and auditors increasingly expect ICT-risk logging and monitoring to cover every system that can move money. Your SIEM now holds an independent copy of DFNS’s audit trail, under your retention policy, searchable by the people answering the examiner. And because it sits in your domain, it is a second, independent record: even in the extreme scenario where DFNS itself were compromised, your SOC holds the history.

Webhooks build. SIEM Export defends.

DFNS gives you several channels out of the platform, and they are designed to be combined rather than chosen between.

  • Webhooks are for building: operational events your application needs to act on, a transfer confirmed, an incoming deposit, an approval pending, a policy triggered. They power products. SIEM Export is for defending: the security audit trail, for your SOC, on a separate channel with separate failure isolation. Both together mean your product team and your security team each get exactly the feed they need, and neither can break the other’s.
  • Add the rest of the platform and a detection becomes a response. The Policy Engine enforces the rules before anything signs; SIEM Export shows you every time those rules were tested. The Governance Engine keeps a tamper-evident ledger inside DFNS and verifies integrity per Org; SIEM Export gives you an independent copy outside it. Transfer Screening and KYT integrations generate the compliance signals; SIEM Export puts them where your analysts already work. And when your SOC sees something, the same API that generated the event lets you act on it: suspend an Org through Tenants, revoke a user’s access and every permission with it, tighten a policy, or have your Validation Gate endpoint return deny for the affected wallets. Detection in your SIEM, enforcement below the DFNS API, and the loop closes in minutes.

Getting started

SIEM Export ships with Datadog Cloud SIEM first. Enablement is two steps:

  1. DFNS activates the capability for your Tenant, and you configure the Datadog integration per Org, your API key, your Datadog site, and any tags you want appended.
  2. From there, every resolved signed action flows.

Version one forwards the signed-action audit trail, one log per event. Broader event coverage and batching follow. And because the forwarder is built provider-agnostic, additional SIEMs are next, with Microsoft Sentinel among the first.

Get started:

Contact us