Push Security

F Push browser identity security platform (REST API v1)

The Push REST API takes only a static x-api-key header, with no federation and no documented expiry, key-management API or last-used date. Into your identity providers it uses admin consent (Microsoft 365, Google Workspace) and an Okta-issued client secret, while the SIEM connectors want pasted API keys, HEC tokens and Entra client secrets.

Docs: pushsecurity.com · Checked 2026-10-13 · source YAML · dispute via PR

Inbound F

How a workload running anywhere authenticates to this product.

Static API key created in the Push admin console (Read only or Full access), sent in an x-api-key header; no OAuth, no token exchange, no workload identity federation.

pushsecurity.com checked 2026-10-13
“To interact with the Push Security API, you'll need an API key for authentication.”
pushsecurity.com checked 2026-10-13
“To authenticate your API requests, include a header named x-api-key and set its value to your API key.”
pushsecurity.com checked 2026-10-13
“set the Value data field to the value provided in the token.txt file generated in the Push app”
pushsecurity.com checked 2026-10-13
“Download the provided config file, which is specific to your team.”

The OpenAPI description (rest-v1.yaml) defines only the x-api-key scheme and one EU server. The browser extension enrolls to a tenant through a team-specific "token" value that the admin generates in the console and pushes to every managed browser as extension policy (Chrome/Edge/Firefox registry or policy.txt via Google Admin). In effect this is a tenant-wide static enrollment secret that sits in the clear in browser policy on every device, and the public docs say nothing about rotating or expiring it. With the automatic licensing option on, the extension then identifies the user from an open Gmail or Outlook tab. No federation option exists for API clients, so the hygiene count decides the grade. With 1 of 5 checks passing, that grade is F.

Outbound B

How this product reaches into your cloud, repos, or other SaaS.

Admin consent to Push's multi-tenant OAuth app for Microsoft 365 and domain-wide delegation for Google Workspace (keyless); Okta via an OIN "Install & Authorize" integration whose client secret is copied into Push; SIEM destinations need pasted static credentials (Datadog API key, Splunk HEC token, Entra app client secret for Sentinel).

pushsecurity.com checked 2026-10-13
“You can integrate Push with Microsoft 365 or Google Workspace via an API integration that uses OAuth.”
pushsecurity.com checked 2026-10-13
“Consent to the OAuth integration screen. For Google Workspace, you'll also need to give permission to Push through domain-wide delegation.”
pushsecurity.com checked 2026-10-13
“To integrate with Okta, you'll use a client secret, your Okta domain, and your client ID to complete the integration configuration.”
pushsecurity.com checked 2026-10-13
“In Okta, select Install & Authorize to install the integration and generate your client secret.”
pushsecurity.com checked 2026-10-13
“Input your Datadog API key and URL into the API key and Site fields.”
pushsecurity.com checked 2026-10-13
“Input the Token Value and your Splunk Cloud HTTP Event Collector URL.”
pushsecurity.com checked 2026-10-13
“Note your client secret's expiry date and set a reminder to rotate it before then.”

Push does not connect to AWS, GCP, Azure subscriptions, GitHub, Slack or Salesforce. Most of its telemetry comes from the browser extension. Connectors checked: Microsoft 365 (admin consent, keyless, with per-scope opt-out that includes write scopes such as Application.ReadWrite.All and MailboxSettings.ReadWrite), Google Workspace (OAuth plus domain-wide delegation, keyless), and Okta (Push's OIN API service integration). Okta is counted as keyless under the cohort rule for vendor-owned OIN service apps, but the customer still copies an Okta-generated client secret into Push, and Okta does not support per-scope configuration. Outbound SIEM/SOAR delivery: Datadog (static API key), Splunk Cloud (HEC token), and Microsoft Sentinel via the Logs Ingestion API (a customer-created Entra app client secret that expires and must be rotated by hand). The generic webhook path, used for Panther, Cribl, SentinelOne, Tines and Slack, sends to a destination URL with optional custom headers, and the docs say it works only if the SIEM accepts ingestion with authentication method "none". Graded B because the IdP connectors are keyless and the SIEM connectors want static credentials. Even with SIEM sinks excluded, the pasted Okta client secret would hold the grade at B.

Hygiene for any static credential the product still issues

✗ Expiry enforceable	Key creation offers a permission level and nothing else. No expiry field or org expiry policy is documented anywhere in the public API or admin docs. pushsecurity.com checked 2026-10-13 “When generating a new key, you have two permission levels to choose from: Read only and Full access.”
✗ Rotation via API	The OpenAPI spec covers employees, accounts, apps, browsers, controls, findings, detections and webhooks, but has no API-key endpoints. Keys are created and revoked only in the console. pushsecurity.com checked 2026-10-13 “To create or manage your API keys, go to the [Settings](https://console.pushsecurity.com/app/settings/api-keys) page in the Push admin console.”
✓ Scoped keys	This passes narrowly. There are only two tiers (read-only vs everything), with no per-resource or per-endpoint scopes. Keys belong to the tenant, not to an individual admin. pushsecurity.com checked 2026-10-13 “A Read only key lets you make GET requests, while Full access allows for all types of requests.”
✗ Last-used visible	The admin docs describe the API Keys settings tab and an "API key added or removed" audit event. Nothing public documents a last-used timestamp for a key. pushsecurity.com checked 2026-10-13 “Add and manage API keys from this section. API keys are used to interact with the Push REST API and share your Push data with other platforms.”
✗ Leak revocation	Push Security does not appear as a provider on GitHub's secret-scanning partner list. docs.github.com checked 2026-10-13

Notes

All docs cited are public: the help center and the REST v1 reference with its downloadable OpenAPI file. The admin console (console.pushsecurity.com) requires login, so the API-key settings screen could not be inspected. An expiry picker or last-used column could exist there without being documented. Outbound webhooks are signed with a Push-issued webhook secret key, which is a static secret in the other direction. Grade only moves if Push adds token exchange or federation for API clients, or at least key expiry, a key-management API and last-used tracking.

Badge

[![wif.tax grade](https://wif.tax/badge/push-security.svg)](https://wif.tax/p/push-security/)