[Developers]

Authentication Audit Logging Pipeline

After a brute-force campaign against a government agency's platform accounts, the security team needs to reconstruct exactly what happened: which accounts were targeted, which IPs were involved, when lockouts triggered,

Category: ModulesLast Updated: Apr 2, 2026
modulesaireal-timecompliance

Overview#

After a brute-force campaign against a government agency's platform accounts, the security team needs to reconstruct exactly what happened: which accounts were targeted, which IPs were involved, when lockouts triggered, and whether any successful logins followed a series of failures. That reconstruction is only possible if the authentication event record is complete, consistent, and queryable. The Authentication Audit Logging Pipeline guarantees that by writing every authentication event to both the document store and PostgreSQL in the same operation.

The dual-write design closes a practical gap: lockout state fields can fall out of sync when only one persistence layer is updated. With every event mirrored to PostgreSQL, structured queries against account lockout status always return current information, not a stale snapshot from a partially-completed write.

Open Standards#

  • OWASP Application Security Verification Standard (ASVS) v4, V2.8 / V6.2.8: Hash-chained audit event integrity uses constant-time comparison as required by ASVS V6.2.8, and the account lockout policy enforced per-event satisfies the brute-force protections defined in ASVS V2.8.
  • Common Event Format (CEF): Audit log records are exported in ArcSight CEF (version 0) so that any SIEM platform (Splunk, Microsoft Sentinel, Elastic, QRadar) can ingest authentication events directly without transformation.
  • ISO/IEC 27001:2022: The dual-write pipeline and structured auth log schema provide the authentication-event audit trail required as evidence for ISO/IEC 27001 Annex A controls covering access control and logging.
  • NIST FIPS 180-4 (Secure Hash Standard): Each audit event record is integrity-protected using SHA-256 (primary), SHA-512, and SHA3-256 digests as defined in FIPS 180-4, ensuring tamper-evidence across both persistence layers.
  • GDPR (Regulation (EU) 2016/679), Articles 25 and 32: Organisation-scoped query isolation and structured capture of IP address and user agent per authentication event directly addresses the data-protection-by-design (Article 25) and security-of-processing (Article 32) obligations.
  • RFC 7519, JSON Web Token (JWT): Session tokens returned after a successful login event are JWT-format bearer tokens, and the audit log records the session transition from lockout-cleared state to active token issuance.
  • SOC 2 Trust Services Criteria (AICPA TSC 2017): The immutable, sequenced audit log with retention controls and tenant-scoped queries provides the logical access monitoring evidence required for the Security and Availability trust service criteria.

Last Reviewed: 2026-04-02 Last Updated: 2026-04-14

Key Features#

  • Dual-Write Consistency: Authentication events are written to both the document store and PostgreSQL in every operation. Lockout state fields are mirrored to PostgreSQL after every update, so structured queries always reflect current state.
  • Structured Auth Log Records: Each entry captures event type, user identifier, tenant identifier, IP address, user agent, timestamp, and extensible metadata. Event types include login_failed, account_locked, login_success, and lockout_reset.
  • Account Lockout Mirroring: When a failed login triggers a lockout, the lockout state is persisted to PostgreSQL in the same operation. When lockout state is cleared, the cleared state is mirrored immediately.
  • Cross-Path Coverage: Both the standard web authentication path and the mobile authentication path generate identical auth log records, ensuring consistent audit coverage regardless of authentication method.
  • Organisation-Scoped Queries: All auth log queries are scoped by tenant and organisation, preventing cross-tenant visibility into authentication events and satisfying data sovereignty requirements.
  • Upsert Semantics: Auth log persistence uses upsert (ON CONFLICT UPDATE) semantics on the log identifier, preventing duplicate entries from retry logic or transient failures.

Use Cases#

  • Security Incident Investigation: Query the authentication audit log for all failed login attempts against a specific user or from a specific IP to identify brute-force attacks, credential stuffing, or compromised accounts
  • Compliance Reporting: Generate audit reports showing all authentication events for a tenant over a defined period, with structured fields suitable for SOC 2, ISO 27001, and EDF compliance evidence
  • Lockout Diagnostics: Trace the sequence of failed login attempts that triggered a lockout, including IP addresses and user agents, to support help desk resolution and forensic review
  • Operational Monitoring: Track authentication event volumes and failure rates across the platform to detect anomalous patterns indicative of systemic issues or coordinated attack campaigns

Integration#

The auth logging pipeline feeds into the platform-wide audit trail for unified event visibility, the security monitoring dashboard for real-time authentication metrics, and the compliance reporting system for regulatory evidence packages. All auth log entries are accessible through the admin interface and the platform API, scoped to the requesting organisation.

Ready to Build?

Get started with our APIs or contact our integration team for support.