Your Okta logs are already a security feed

Engineering already trusts Datadog. It watches production, it watches the cloud accounts, it knows when a service is unhealthy, and when it has something to say it says it somewhere people actually read. That trust took a while to build, and it is worth something.

Meanwhile Okta is quietly writing down changes that matter at least as much as a failing service. Somebody was granted administrator. Somebody's MFA was reset. An API token was created at two in the morning. A new identity provider was added to the tenant. All of it is recorded and searchable, and at most companies none of it goes anywhere until somebody goes looking after the fact.

Those two things do not need to live in separate worlds. Sending a small number of consequential identity events into a platform the company already runs is a modest piece of work, and at thirty or a hundred people it is a real improvement. No new contract, no new console, nothing extra for anybody to remember to check.

How long each platform keeps evidence, and how far back an investigation can reach, is a separate subject, covered in these Technical Notes under "You cannot investigate what you did not retain". This one is about which events are worth routing and where they should land.

The changes worth hearing about

Start by deciding what not to send. A channel that receives every failed Okta login is ignored within two weeks, and the cost is not the noise, it is the real event that arrives in the middle of it. What is worth routing is the small set of changes that alter who can do what, and each is rare enough to deserve half a minute of somebody's attention.

A new API token, system.api_token.create, should be infrequent and should have a reason behind it. Tokens get created for integrations, integrations are usually planned, and a token nobody can account for is either an undocumented project or somebody arranging a way back in. Datadog ships a detection for this event, which is a fair signal it is the one to watch.

Administrative privilege grants matter more than almost any sign-in, Super Administrator and Organization Administrator most of all. Okta's own security guidance suggests matching event types that end in privilege.grant rather than naming one, and the reason is worth knowing: that pattern also catches a grant made to a group, where a single change can elevate several people at once.

An MFA reset, user.mfa.factor.reset_all, is ordinary help-desk work on its own. What matters is that reset followed by user.session.access_admin_app, and there is an out-of-the-box detection for exactly that pair. Attacks on multi-factor authentication increasingly do not bother with the protocol; they call the service desk and ask for a reset. The reset looks legitimate; the console access a few minutes later is what makes it a pattern.

A new identity provider, system.idp.lifecycle.create, changes who is trusted to authenticate your people, and should not appear without a project behind it. Application lifecycle changes are usually audit material rather than a reason to interrupt anyone, with a short named list of high-value applications as the exception. Authentication failures are worth watching only with a threshold or anomaly logic behind them.

In practice that sorts into three rough buckets, and the sorting is judgement rather than a framework.

• Look now: a new Super or Organization Administrator, an MFA reset followed by administrative console access, a new identity provider, an API token nobody expected.
• Look this week: authentication from unexpected infrastructure, odd session or device behavior, failures above whatever normal turns out to be.
• Watch the trend: general failure rates, lifecycle volumes, provisioning errors, policy changes.

A hundred-person company does not need the notification model of an organization processing millions of events a day. Half a dozen well-chosen events will do more good than a large rule set nobody maintains.

The chain is short. Okta writes the event, the integration puts it in Datadog, a monitor or rule recognizes it, and a message reaches a person. Only the last step is the control; everything before it is plumbing.

Where the alert should land

For a smaller company, success here looks unglamorous. A consequential identity change happens, and a short message appears in a channel that the IT owner, the CTO, the COO or whoever actually holds the environment can see. Somebody reads it and asks whether that change was expected. If it was, nothing happens. If it was not, somebody starts looking.

That is a genuine improvement on finding out days later while searching the System Log for something else. It asks nobody to remember a dashboard and needs no rota. It needs the message to arrive where people already are, which usually means the same Slack workspace the production alerts go to.

Which puts some weight on what the message actually says. Carry the affected user, the actor where Okta records one, the event type, the source address and any location context, the target object, a link back to the event, and one line about what to do with it:

• Okta API token created
• User: admin@example
• Source: unexpected network
• Time: 02:14
• Action: confirm an approved change exists; otherwise investigate immediately.

The thing worth being strict about is ownership. A channel where everyone can see an alert and nobody owns it produces roughly the same outcome as no alert at all. Name the person, or name the rota, before routing the first event.

From there, Datadog workflows can be triggered by a monitor or a security signal and can open a Jira issue and post to Slack with a link to it in the same run. Opening a ticket is the dull part that matters: it gives the event an owner and a state, so nobody has to remember what happened to it.

Be careful at the destructive end. Suspending an Okta user or killing their sessions on one unverified signal will eventually lock out the wrong person at the wrong moment, and the recovery path is the same help-desk process several of these detections exist to protect. Automate context, notification and escalation. Leave the disabling to a person until the detection has earned more than that.

Most of this runs on what you already pay for

None of the above needs a security product. The Okta System Log lands in the same place as the operational telemetry, which is most of the value by itself: the identity record and the application record sit side by side at the same timestamps. Monitors are built on log queries and route to Slack or email with the event attached.

Two constraints shape the design, and both are better known in advance than discovered. A log monitor evaluates indexed logs only, and it has a maximum rolling time window of two days. So anything you intend to alert on has to be in an index, and a monitor cannot be the mechanism for anything needing a longer baseline.

That is what the other two tiers are for. Log-derived metrics are generated from everything ingested, including logs excluded from indexes, and kept at ten-second granularity for fifteen months, which is how trends stay cheap. Archives forward the ingested stream, indexed or not, to storage the company owns in Amazon S3, Azure Storage or Google Cloud Storage, and rehydrate when an investigation needs them. Index what you alert on, measure everything, archive the rest.

A dashboard covering failures, resets, administrative activity and lifecycle volumes is easy to build and useful for a weekly look. It is not detection. Nobody is watching it at two in the morning, which is when a fair number of these events happen.

When a specialist platform earns its place

None of this makes Log Management a SIEM, and it should not be sold as one. Datadog's Cloud SIEM is enabled separately and adds what a security platform is actually for: an Okta content pack, out-of-the-box detection rules, security signals, correlation across sources and somewhere to work an investigation.

It earns its cost at the point where an Okta event stops being a single fact. Once the same platform is receiving cloud, endpoint and application telemetry, a suspicious session, then privileged access to an application, then unusual activity inside the connected system is one story, and plain log monitors will not assemble it for you. That is worth paying for when the environment produces that kind of sequence.

What it is not is a default. Ask first what security telemetry the company already generates, which platform can ingest it, where alerts already go and who reads them. If that produces a meaningful improvement using something already paid for, take it. Add a specialist platform when scale, risk or regulation calls for one, not because the category exists.

And be honest about the edges. None of this substitutes for the following where they are genuinely required.

• A mature SIEM, where correlation across many disparate sources is the requirement
• A staffed security operations team, or 24 by 7 monitoring
• Endpoint detection and response
• Incident response capability
• Formal retention under a regulatory obligation
• Threat hunting and detection engineering specific to the business

Then ask what else you already own

The interesting part of this is not the Okta integration. It is the question underneath it, which most companies never quite get around to: what are we already paying for that could be doing more than it currently does?

Monitoring platforms, identity systems, endpoint tooling, cloud providers and collaboration suites all ship with capability that goes unused, usually because the thing was bought for one job and nobody revisited it. A company that already trusts a platform, already has it wired into its alerting and already has people reading those channels is better placed to extend it than to buy a competitor alongside it. Fewer contracts, fewer consoles, one less system nobody quite owns.

Security spending is easier to justify when it starts there. Sometimes the answer really is a new product. Often it is a configuration, an integration, and a decision about who reads the channel.

What I would verify before calling this done

Connecting the two and watching logs arrive is not the same as being finished. For each event worth having, generate it deliberately and follow it the whole way.

• The Okta event you expect is actually generated
• Datadog receives it
• The query or rule catches it
• The message reaches the channel you intended
• It carries enough context to decide whether the change was expected
• Somebody owns what happens next, by name
• The event can still be found months later, during an audit

It is the same discipline as testing that revocation actually revokes rather than confirming that a group membership changed. A detection that has never been deliberately triggered is still partly theoretical, and the morning it matters is a bad time to find out that an exclusion filter took those events out of the index.

Product note. Datadog's Okta integration, log monitor behavior and Cloud SIEM detection content are moving quickly. This note reflects Datadog's and Okta's documented behavior as reviewed in August 2026 and should be revalidated against current documentation before it is used as a configuration reference.

Explore this expertise: Identity & Access Management

All technical notes