Other SecOps leads often ask me the same question: we federated everything through Ping, so which logs should we forward? Last year I sat in on a detection review at a company that had streamed PingOne webhook events into Splunk for a full quarter, and I watched the cost of answering that question badly. Their impossible travel rule had never fired once.
When we pulled a raw event, the reason was obvious: not a single record carried a source Internet Protocol (IP) address, because the team's webhook subscription had never been configured to include one.
So I no longer treat Ping single sign-on (SSO) as one log source. In PingOne, webhook subscriptions include IP addresses and user-agent strings only when an administrator selects them. The products in play, plus the defaults accepted at install, decide whether the detections an identity program needs can fire at all.
Sort out which products and settings are in scope before any analyst writes a rule.
In brief:
- PingOne and PingFederate have materially different logging models, so they shouldn't share one security information and event management (SIEM) integration plan.
- PingOne webhooks include IP addresses and user-agent strings only when an administrator selects them, so a PingOne-only impossible-travel rule isn't viable without that opt-in.
- PingFederate's audit logging fails silently: setting audit.log, provisioner-audit.log, or transaction.log below INFO turns it off entirely, with no error.
- Public detection content for Ping is thin and mostly PingID and PingOne multi-factor authentication (MFA) activity, so expect to adapt broader identity rules to your schema.
What Ping SSO is, and why the distinction matters
Ping's documentation defines PingOne SSO as signing on to all your applications with one set of credentials over Security Assertion Markup Language (SAML), OAuth, and OpenID Connect (OIDC), but that is procurement language, not a collection plan.
In production, Ping SSO can mean several distinct products: PingOne Platform (multi-tenant software as a service, or SaaS), PingFederate (self-hosted federation), PingID (MFA), PingOne Advanced Identity Cloud (renamed ForgeRock), and DaVinci (orchestration).
Each exposes a different event model, transport, retention window, and licensing constraint, so a detection written against the wrong product or namespace sits green in the SIEM and never fires.
This piece focuses on PingOne Platform and PingFederate; its PingFederate examples use the 13.1 documentation set, so verify equivalent paths for your release.
PingOne (cloud) and PingFederate (self-hosted) log differently
PingOne is a SaaS platform: operators reach audit data through the console, APIs, and webhook subscriptions rather than local log files. A single audit query covers a maximum 14-day span; older data must first be pulled through an asynchronous request that takes 2 to 24 hours, depending on volume and period.
Documented retention windows run 90 days for user events and two years for admin configuration events. DaVinci keeps its own separate audit events and retention, so treat it as a distinct source rather than a PingOne retention category.
PingFederate writes local Log4j 2 files to /pingfederate/log/ in self-managed deployments, giving operators direct control over forwarding, rotation, and retention. The named log files include audit.log, admin.log, admin-api.log, provisioner-audit.log, runtime-api.log, and transaction.log, and rotation and retention follow the log4j2.xml configuration.
Keep that configuration consistent across cluster nodes; configuration management can automate it rather than relying on manual syncing.
One gotcha earns a permanent spot in my deployment reviews. PingFederate's audit logging fails silently: set audit.log, provisioner-audit.log, or transaction.log to any level below INFO and that logging turns off entirely, with no error. Someone tuning noise with a WARN level kills the audit trail unnoticed.
The Ping log events the SOC needs
Identity attacks in these products center on credential and MFA abuse and configuration tampering, while provisioning and token misuse create a separate forwarding requirement. Those two facts decide which event families and log files belong in the forwarding plan.
Authentication and MFA events
On PingOne, the action.type field carries the signal. Ping's Audit Reporting Events reference is the canonical list, and it includes values such as AUTHENTICATION.CREATED, SESSION.CREATED, PASSWORD.CHECK_FAILED, OTP.CHECK_FAILED, DEVICE.ACTIVATION_OTP_FAILED, USER.LOCKED, USER.UNLOCKED, and MFA_SETTINGS.UPDATED, where OTP means one-time password.
Don't assume MFA push approval or denial event names from examples; export representative events from the tenant and confirm the exact action.type, result, device, and IP fields before writing rules.
PingFederate's security audit logging documents event values such as AUTHN_REQUEST, AUTHN_ATTEMPT, SSO, SLO, and AUTHN_SESSION_CREATED, with status values of success, failure, and inprogress.
The pipe-delimited fields carry subject, ip, connectionid, and protocol, plus a trackingid that ties messages together for a session; confirm exact values against your release. The trackingid is the field an analyst uses to reconstruct a session, so preserve it in the parser.
Admin and configuration changes
PingOne's two-year retention on admin console events outlasts most SIEM budgets.
Documented action.type values cover deletions (APPLICATION.DELETED, IDENTITY_PROVIDER.DELETED, CERTIFICATE.DELETED), config updates like SIGN_ON_POLICY_ASSIGNMENT.UPDATED, and role assignments, which show readable role names rather than universally unique identifiers (UUIDs).
Webhooks also support an Admin Identity Event subscription for actions taken on other administrators.
PingFederate splits admin telemetry across files. admin.log carries timestamp, user, roles, IP, component, and event. admin-api.log adds the HTTP method, representational state transfer (REST) endpoint, status code, and, when the OAuth 2.0 private-key JWT admin application programming interface (API) is used, a JSON Web Token (JWT) ID.
admin-event-detail.log holds the change records and is written only when detail logging is on (pf.log.eventdetail=true).
One limitation is worth checking directly. Validate whether changes made through external client stores, including Lightweight Directory Access Protocol (LDAP) and Java Database Connectivity (JDBC) datastores, are represented in the admin audit trail, rather than assuming it captures every external change.
Provisioning, session, and token events
PingFederate routes these to files easy to overlook. Outbound provisioning is excluded from audit.log and lands in provisioner-audit.log with event_type, is_success, and non_success_cause fields. Session Revocation API actions go to runtime-api.log, so a security operations center (SOC) forwarding only audit.log won't see a revocation.
For token abuse, audit.log carries grant and token identifiers that can support correlation across PingFederate and PingAccess where they're preserved. On PingOne, the lifecycle signal comes through USER.DELETED, USER.UPDATED, USER.LOCKED, and the USER.SLO_* logout family.
Those are user events, which means 90-day retention: an OAuth token investigation reaching back a quarter depends on what was streamed out before the window closed.
What Ping makes easy, and what it buries
Ping supports several output formats, but its stingy defaults quietly kill detection coverage.
Where the useful signal is, and where you have to dig
PingFederate natively supports Common Event Format (CEF) over syslog, a dedicated splunk-audit.log, JSON templates, and JDBC output, and exposes six audit loggers, so OAuth authorization server events can route separately from SAML browser SSO. PingOne webhooks push events to a SIEM over HTTPS or TCP/IP streaming.
Third-party integrations vary in coverage: Expel's PingOne integration, for instance, adds detection rules but audit-log access can require a higher PingOne tier, so verify scope and licensing against your contract.
Since that failed detection review, I open every Ping integration the same way: pull one raw event and grep for an IP field before anyone talks dashboards.
Getting Ping logs into the SIEM without the noise
Forwarding everything from an identity provider (IdP) grows the SIEM bill without growing coverage.
What to forward, what to drop, how to normalize
Prioritize failed authentications, MFA failures or anomalous challenges, lockouts, privileged configuration writes, role and identity-provider changes, provisioning failures, and session revocations. Evaluate read-only and API telemetry separately by risk and volume.
Route routine successful sign-ins and sign-outs to lower-cost storage rather than dropping them, since they still matter for session reconstruction and incident response.
To keep data past the standard windows, stream events via webhooks under your own retention policy. Archive full-fidelity data to cheap storage and send only high-signal events to the SIEM, which keeps investigative depth without making routine activity the most expensive part of the feed.
PingOne webhooks push over HTTPS or TCP/IP streaming; for high-volume collection, prefer subscriptions over periodic API pulls and validate current batching and rate limits for your tier.
For normalization, the webhook Splunk audit format is intended for Splunk-oriented ingestion, so validate Common Information Model (CIM) field mapping in your environment.
On Microsoft Sentinel, the PingFederate connector is deprecated; CEF via the Azure Monitor Agent (AMA) is the supported path.
The detections these logs make possible
Every routing decision above exists to make a few detections fire, each tied to attacker behavior documented in the last three years.
Impossible travel, MFA fatigue, and admin abuse from Ping data
An impossible-travel analytic needs a stable user identifier, ordered event times, a trustworthy location signal (usually a client IP enriched with GeoIP), and suppression logic for VPNs, mobile carriers, proxies, and expected travel.
PingFederate audit logs can provide an IP field, but validate what it represents behind reverse proxies; PingOne provides it only with the webhook opt-in, and even then it can be a proxy.
I found no current vendor-published PingOne or PingFederate impossible-travel rule, so adapt the pattern from Elastic's Okta geolocation rule as a design reference, not a drop-in, remapping fields to Ping's schema.
MFA fatigue maps to MITRE ATT&CK technique T1621, and it isn't theoretical. Scattered Spider repeatedly sent MFA prompts until victims accepted the push, then registered its own MFA methods and added a federated identity provider to the tenant, per CISA's updated Scattered Spider advisory.
Public detection content for Ping is thin and mostly targets PingID and PingOne MFA activity, not PingFederate federation telemetry.
Splunk Security Content ships PingID analytics for repeated failed MFA requests, new MFA-method registration, new enrollment after a credential reset, and auth-versus-verification mismatches.
Validate each rule's product scope and data-source requirements before deploying; the credential-reset analytic, for instance, also needs Windows domain-controller events for the password-reset half of the correlation.
For admin abuse, alert on IDENTITY_PROVIDER and ROLE_ASSIGNMENT events in PingOne and on admin-api.log endpoints touching connections and OAuth settings in PingFederate. Treat any new or modified federated IdP as high priority, with an allowlisted change window and owner validation.
This week, run a raw-event validation exercise. For PingOne, confirm the subscription carries the authentication and admin event families you need, with IP and user-agent inclusion enabled.
For PingFederate, confirm the relevant audit loggers sit at INFO or above, and that detailed administrator logging is enabled and forwarded where its investigative value justifies the volume.
The SIEM line is one of the biggest checks I write, and the Ping feed keeps its slot only because these detections fire from it.
Frequently asked questions about Ping SSO logs
What Ping products count as "Ping SSO"?
"Ping SSO" is procurement shorthand, not one log source. In practice it can span PingOne Platform (SaaS), PingFederate (self-hosted federation), PingID (MFA), PingOne Advanced Identity Cloud (formerly ForgeRock), and DaVinci (orchestration).
Each has its own event names, access model, transport, and retention, so identify the products in scope before designing collection.
What Ping logs should you send to your SIEM?
From PingFederate, forward the security audit, admin, admin-api, provisioner-audit, and runtime-api logs, since session revocations and provisioning events never reach the main audit file. From PingOne, configure a webhook subscription covering authentication, MFA, and admin events with IP and user-agent inclusion selected.
Prioritize privileged changes and route routine successful activity to lower-cost storage rather than dropping it.
What is the difference between PingOne and PingFederate logging?
PingOne is multi-tenant SaaS with no filesystem access; audit data arrives through the admin console (14-day query span), webhooks, or the /activities API, retained 90 days for user events and two years for admin configuration events.
PingFederate writes Log4j 2 files to /pingfederate/log/ under operator control in self-managed deployments, with retention set by log rotation and forwarding via CEF syslog, Splunk output, JSON, or JDBC.
What attacks can Ping SSO logs help detect?
Ping SSO logs support impossible-travel and MFA-fatigue detection, and expose admin abuse through rogue role assignments, MFA-method changes after a reset, and new federated identity providers in the tenant.
Public detection content is limited and mostly PingID/PingOne MFA-focused; PingFederate federation telemetry has far less published coverage. Expect to adapt broader identity rules, such as Okta or Entra content, by mapping fields to your Ping schema.