Purpose
This guide explains how to forward Securify Identity (SecurifyID) events to Logsign USO over syslog and what Logsign does with them. The integration covers the MFA and authentication events produced by SecurifyID (primary authentication, OTP and push confirmations, policy and rule decisions), self service password and account operations, approval workflows, management console actions, and system events such as directory synchronization, license status and brute force prevention.
Prerequisites
- A Securify Identity administrator account that is allowed to change the log forwarding settings.
- Network connectivity from the Securify Identity server (or every node of a cluster) to the Logsign USO collector on your syslog port (TCP or UDP 514 by default).
- The Logsign user account that will add the data source needs access to Settings > Data Collection.
- A Logsign USO release that includes the Securify Identity parser. If you are not sure whether your version includes it, contact Logsign support before you start.
Step 1: Forward Securify Identity logs to Logsign
Securify Identity sends its logs from the log forwarding settings of its management console. Menu names can differ between releases, so use the Securify Identity documentation for your version to find the remote syslog settings. Add the IP address of the Logsign USO collector and the syslog port there.
The product offers three output formats: plain syslog, CEF and LEEF. Logsign accepts all three, because in each of them the event body is the same Python dictionary text. CEF and LEEF do not add any information on top of that body, so we recommend the plain syslog format.
Step 2: Add the data source in Logsign USO
Open the Logsign USO web interface and click + Device under Settings > Data Collection. Choose Syslog as the collection method, select Securify as the vendor and Identity as the product, and enter the IP address of the Securify Identity server as the host. Click Save. Once the server starts sending, events appear under Search.
Supported message format
Every Securify Identity message carries a dictionary body that starts with the srcip key. Logsign finds that body anywhere in the message, so the RFC 5424 header and the CEF or LEEF prefix in front of it do not matter. The same event in the three formats looks like this (anonymized):
<13>1 2026-10-07T12:48:11.615579Z securify01 Securify Identity - - - {'srcip': '203.0.113.18', 'userid': 'user.one', 'service': 'VPN', 'logtype': 'confirmation_success', 'actionreason': '', 'platform': 'ios', 'timeperiod': '', 'agent': '', 'riskscore': 0.0, 'screensize': '320x693', 'server_name': 'securify01', 'server_ip': '10.0.0.80', 'datetime': '2026-10-07 15:48:11', 'console_user_name': '', 'ip_geolocation': '', 'asn': '', 'isp': ''}
<13>1 2026-10-07T13:15:50.743139Z securify01 Securify Identity - - - CEF:0|Securify|SecurifyID||0|SecurityEvent|4|src=securify01 msg={'srcip': '', 'userid': 'service.account', 'service': 'SSH-Switch', 'logtype': 'primary_auth_success', 'actionreason': 'Primary Auth is successful. LDAP ', 'platform': 'Other', 'timeperiod': '', 'agent': '', 'riskscore': 0.0, 'screensize': 'x', 'server_name': 'securify01', 'server_ip': '10.0.0.80', 'datetime': '2026-10-07 16:15:50', 'console_user_name': '', 'ip_geolocation': '', 'asn': '', 'isp': ''}
<13>1 2026-10-07T13:24:27.005183Z securify01 Securify Identity - - - LEEF:2.0|Securify|SecurifyID||SecurityEvent src=securify01 msg={'srcip': '', 'userid': 'user.two', 'service': 'Remote Access', 'logtype': 'sent_confirmation', 'actionreason': '', 'platform': '', 'timeperiod': '', 'agent': '', 'riskscore': 0.0, 'screensize': 'x', 'server_name': 'securify01', 'server_ip': '10.0.0.80', 'datetime': '2026-10-07 16:24:27', 'console_user_name': '', 'ip_geolocation': '', 'asn': '', 'isp': ''} sev=noticeThe body must reach Logsign as a single message and must contain a logtype key. Messages without a readable dictionary body or without logtype are not recognized as Securify Identity events.
What gets collected
Logsign fills the following fields from the Securify Identity keys. A field only appears on an event when the corresponding key has a value in that message.
| Logsign field | Securify Identity key |
|---|---|
| Source.IP, Source.City, Source.Country | srcip (city and country come from Logsign GeoIP lookup on the address) |
| Source.UserName | userid for authentication events, console_user_name for administrative events (see below) |
| Target.UserName | userid for administrative events (see below) |
| Source.OS | platform |
| Browser.Name | agent |
| Service.Name | service |
| Event.Category | logtype |
| Event.Info | actionreason |
| Event.Action | Readable name of the logtype, for example Primary Auth Success |
| Risk.Level | riskscore |
| Device.HostName | server_name |
| Device.IP | server_ip |
| Time.Generated | datetime (format YYYY-MM-DD HH:MM:SS) |
| Time.Zone | timeperiod |
For most events userid is the person who authenticated, so it goes to Source.UserName. Administrative events work the other way round: userid is the account that was changed and console_user_name is the administrator who made the change. For console_action, audit, delete_models_success and every 2fa_disabled type, and for any event that has a value in console_user_name, Logsign writes userid to Target.UserName and console_user_name to Source.UserName.
Every event is recorded with Vendor Securify, Product Identity, EventSource Type Security System, EventSource Category Access Control and EventSource PrefixID 4529.
Event classification
The logtype value decides the EventMap, Event.VendorID and severity of each event. The table groups the log types by EventMap.
logtype values | EventMap | EventMap.ID | Severity |
|---|---|---|---|
success_otp_login, confirmation_success | Identity / User / Login | 10101 | information |
block_rule, policy_block, behavioral_biometrics_fail | Identity / User / Deny | 10102 | warning |
console_action, audit, self_service, primary_auth_success, calculated_risk, factor_rule, escalated, behavioral_biometrics_success, sent_confirmation, opened_totp_page, generated_qrcode, geolocation_result, approval_auto_cancelled | Identity / User / Info | 10111 | information |
jit_update_fail, approval_error, acc_unlock_fail, confirmation_error, cofirmation_error, geolocation_error | Identity / User / Error | 10109 | error |
approval_request | Identity / User / Request | 10115 | information |
approved, approval_granted, approval_auto_granted | Identity / User / Grant | 10110 | information |
acc_unlock_success | Identity / User / Unlock | 10113 | information |
external_pwd_reset_success, local_pwd_reset_success | Identity / Password / Reset | 10504 | information |
external_pwd_change_success, local_pwd_change_success | Identity / Password / Change | 10501 | information |
external_pwd_reset_fail, external_pwd_change_fail, local_pwd_reset_fail, local_pwd_change_fail | Identity / Password / Fail | 10503 | information |
allow_rule | Security / Other / Allow | 22004 | information |
rejected, approval_rejected, approval_auto_rejected | Security / Other / Block | 22005 | warning |
brute_force_prevention_activated | Security / BruteForce / Detect | 21001 | alert |
brute_force_prevention_deactivated | Security / BruteForce / Info | 21002 | critical |
2fa_disabled, 2fa_disabled_for_usergroup, 2fa_disabled_for_x_hours_with_ip, 2fa_disabled_for_x_hours_with_browser, 2fa_disabled_for_x_hours_with_ip_and_browser, 2fa_disabled_for_x_hours_with_ip_or_browser | System / Configuration / Change | 70901 | warning |
licence_warning | System / License / Expire | 70402 | warning |
licence_status_update | System / License / Info | 70401 | information |
licence_srv_conn_fail | System / License / Error | 70403 | error |
notification, workflow, directory_sync, scheduled_directory_sync, delete_models_success, test_ivr_sent | System / Operation / Info | 70201 | information |
test_ivr_failed, windows_ldap_fail | System / Operation / Error | 70202 | error |
sent_sms_otp, sms_delivered | Application / SMS / Info | 40302 | information |
sms_delivery_error | Application / SMS / Error | 40301 | error |
sent_email_otp | Application / Mail / Info | 40215 | information |
email_delivery_error | Application / Mail / Fail | 40202 | information |
Any other logtype | Identity / User / Info | 10111 | Syslog priority of the message |
A log type that is not in the table is still collected. It gets Event.VendorID 999 and keeps its original logtype in Event.Category, so you can find it in Search and report it to Logsign support.
Notes and limits
- Securify Identity sends every message with the same syslog priority, so the severity comes from the classification table above and not from the syslog header. Only log types outside the table use the syslog priority.
console_actioncovers all management console operations (add, edit, delete). The operation itself, for exampleIdentity Updated, is in Event.Info. Filter on Event.Info when you need a specific console operation.- When
console_user_nameis empty, Source.UserName stays empty. Logsign does not fill in a default administrator name that is not in the log. - The
screensize,ip_geolocation,asnandispkeys are not mapped to Logsign fields. Source.City and Source.Country are produced by Logsign from Source.IP instead. The raw values stay available in the original log. - Time.Generated is read from
datetimeas the server writes it. The offset that the server reports intimeperiodis kept in Time.Zone.
Verification
After both sides are saved, one MFA login through Securify Identity is enough to check the integration end to end.
- In Logsign USO, open Settings > Data Collection and confirm that the Securify Identity source is receiving data.
- Complete an MFA login through a service protected by Securify Identity. In Search, look for events with Vendor Securify and Product Identity. The login should appear with Event.Category
primary_auth_success,sent_confirmationorconfirmation_success, and your user name in Source.UserName. Aconfirmation_successevent has EventMap Identity / User / Login. - Change a user in the management console. That change should appear as
console_actionwith the administrator in Source.UserName (when the server sendsconsole_user_name) and the changed account in Target.UserName. - If the source is receiving data but no events show Vendor Securify, the messages are not in a format this integration recognizes. Check that each message contains the full dictionary body starting with
{'srcip':and that it is not split or rewritten on the way.