Verified exposure signals for identity risk decisions

Before you start

• LeakData account-owner access with Enterprise SIEM integration access. Seat accounts cannot configure the connection.
• An Okta administrator who can install and authorize API service integrations, and an organization with Shared Signals receiver support. Identity Threat Protection is required for the corresponding risk-policy features.
• An active personal email monitor whose address is ownership-verified or belongs to one of your verified domains. For a signed-signal test, use a controlled sample user with the same email in a test Okta organization.

1. Install and authorize in Okta

The public catalog listing is pending. If LeakData is not available in your catalog, contact support for the current setup path before continuing.

1. Open Applications and Resources > API Service Integrations in the Okta Admin Console and install LeakData Shared Signals when it is available in your catalog.
2. Authorize only okta.securityEventsProviders.manage. Copy the one-time Client Secret immediately, then record the Client ID and Okta domain from that same instance.
3. Use the uncustomized organization origin, such as https://integrator-1234567.okta.com. Remove -admin, paths, query strings and port numbers.

These credentials come from an installed OIN API service integration. An API token or a general OAuth service app created through Create App Integration does not provide the same OIN Client ID/Secret setup.

2. Connect in LeakData

1. Sign in as the account owner and open Dashboard > Integrations > Okta Shared Signals.
2. Enter the organization URL, Client ID and Client Secret from the same authorized instance. Choose High and critical or Critical only.
3. Read and confirm the verified-address boundary and the effect of your Okta risk policies, then select Connect Okta. LeakData verifies the credentials and creates or reuses its security events provider.
4. After setup, the provider is active. LeakData encrypts the secret and does not display it again.

3. Verify the connection

1. Select Check connection to verify credentials and provider state without sending a risk signal. Confirm the provider is active and a provider ID is present in Connection details.
2. Review the eligible email monitors. Only exact email addresses that are ownership-verified or on one of your verified domains are eligible; a domain monitor itself is never sent.
3. In a dedicated Test/QA account and controlled Okta Integrator organization, review the sample email and policy acknowledgement before using Test a signed signal. This test can trigger configured risk policies.
4. HTTP 202 confirms acceptance only. Check Okta System Log for security.events.provider.receive_event and user.risk.detect for your sample user. An unknown email can be silently ignored.

4. Replace credentials or change organizations

1. For the same organization, select Replace credentials and enter a new Client ID/Secret pair from an authorized LeakData API service instance in that organization. Saving verifies and activates the connection.
2. Pause delivery keeps the organization binding and saved credentials. It does not prepare the account for another organization.
3. To resume delivery to the same organization, select Start delivery, then Check connection and confirm that the provider is active.
4. To use a different organization, review Remove connection first. Confirming removal deletes the provider, encrypted credentials and local delivery history. Then set up the new organization. If removal fails, contact support; do not assume the old provider has been removed.

Troubleshooting

Credentials rejected

Check that all three values come from the same installed and authorized OIN API service instance. During review, use an instance of the current submission version. API tokens and generic OAuth service-app credentials are not interchangeable with this setup.

Permission or receiver access denied

Confirm okta.securityEventsProviders.manage was authorized and that your Okta organization supports the SSF receiver. Review administrator access and organization policies.

Already connected to another organization

Replace credentials only for the displayed organization. Pausing does not remove the connection. Review the removal steps above before changing organizations.

No signal or no user risk event

Check that the address is ownership-verified or on a verified domain, the personal monitor is active, the finding is a verified high/critical finding, and the selected severity threshold. Receiver acceptance alone does not prove a user match or policy action.

Need help?

Contact LeakData support with the failed operation and error code. Do not include passwords, Client Secrets, or access tokens.