WorkOS Audit Logs Upgrade: Automatic Capture of Sessions and Membership Changes

WorkOS recently announced that its Audit Logs feature now automatically records user sign-in sessions and membership change events. This means enterprises can obtain more complete compliance audit tracking capabilities without writing additional code. However, this feature is not retroactive—events that occurred before activation will not be backfilled.

Which events are automatically captured?

According to the official documentation, WorkOS now automatically writes audit log events for two key types of operations:

• Sign-in sessions: When a user completes authentication through WorkOS, the system automatically generates a session-related audit event.
• Membership changes: When a user is added to or removed from an Organization, the corresponding change is also automatically recorded.

These two event types are precisely the parts most frequently asked about in enterprise security audits—"who logged into the system and when" and "who was granted or revoked access." Previously, developers had to manually call WorkOS's Audit Logs API to record these actions; now it is done by default.

The source of Directory Sync and membership change events

WorkOS's Directory Sync feature connects with enterprise identity providers (such as Okta, Azure AD, Google Workspace) via the SCIM protocol, syncing user and group data within the organization to the application. Membership change events are generated along this pipeline: when an administrator adds or removes a user from a group on the IdP side, the SCIM push triggers WorkOS to update the organization membership, which in turn writes to the audit log. Understanding this helps assess the coverage of automatic capture—it reflects membership changes flowing through the WorkOS identity layer. If the application also has its own membership management entry point independent of the IdP, those changes will not automatically enter the audit log.

What is not captured?

WorkOS clearly defines the boundaries: automatic capture covers only the two event types above. Other custom business operations (such as modifying configurations or accessing sensitive data) still require developers to actively report through the Audit Logs API. In other words, the automated portion addresses the general audit needs of the "identity layer," but audit responsibility at the business layer remains on the application side.

This design is reasonable—the identity platform can only perceive authentication and membership management actions, while the context of business logic is known only to the application itself. However, teams expecting "out-of-the-box full audit coverage" need to manage their expectations.

Why is activation not retroactive?

An easily overlooked but very important detail: after enabling this feature, the audit log only records events that occur after activation; historical sign-ins and membership changes will not be backfilled.

The reason is that WorkOS did not previously persist these events for audit purposes. Audit logs require independent storage and indexing mechanisms; retroactive backfilling is technically infeasible and also conflicts with the design principles of audit logs—"real-time recording, tamper-proof." Therefore, teams should be mentally prepared before enabling the feature: the compliance audit time window starts counting from the moment of activation.

The design principles of "tamper-proof" and "real-time recording" in audit logs

The key difference between audit logs and ordinary application logs lies in their evidentiary nature. Common industry practice is to use append-only storage, hash chains, or write-once-read-many (WORM) mechanisms to ensure that once a record is generated, it cannot be modified or deleted, thereby providing credibility in compliance audits and security incident investigations. If historical events were allowed to be backfilled after the fact, the backfilled content and real-time records would be indistinguishable in terms of timestamp source and integrity proof, weakening the credibility of the entire log chain. Therefore, mainstream audit log systems generally record only events after activation and treat the "activation moment" as the starting point of audit coverage. This also explains why WorkOS chose not to backfill: technical feasibility is one aspect, but more fundamentally, backfilling would undermine the evidentiary semantics of audit logs.

What it means for developers and compliance teams

For products using WorkOS for enterprise SSO and Directory Sync, this update reduces some integration costs. Especially for SaaS teams targeting compliance requirements such as SOC 2 and ISO 27001, sign-in and membership change logs are common items on audit checklists, and automatic capture eliminates the hassle of separate instrumentation.

However, this also brings an operational reminder: if your compliance audit needs to cover a longer historical period, you should enable this feature as early as possible and simultaneously check the ingestion configuration of downstream log systems (such as SIEM) to ensure events are properly consumed and retained.

Specific log requirements of SOC 2 and ISO 27001

SOC 2 is developed by the AICPA. The CC7 series of controls in its "Security" trust services criteria explicitly require organizations to record and monitor access to system resources, including authentication events and permission changes, and logs must have integrity protection and retention policies. ISO 27001's Annex A controls (such as A.8.15 Logging and A.8.16 Monitoring Activities) likewise require event logs to be retained and regularly reviewed. Neither mandates a specific retention duration, but both require organizations to define periods based on their own risk assessments; audits typically ask about historical traceability of 90 days to 1 year. This is precisely why the "non-retroactive" detail deserves attention: the period before enabling the feature will create a gap in the audit evidence chain, and teams need to compensate with written explanations or alternative evidence (such as IdP-side logs).

Conclusion

This WorkOS update is a pragmatic enhancement: it automates the two types of events that the identity platform can naturally perceive while clearly defining the boundaries of its capabilities. For teams relying on WorkOS, it is recommended to confirm the feature toggle status as soon as possible and assess whether existing audit processes need adjustment.

One-line Summary

WorkOS Audit Logs automatically record sign-ins and membership changes, but do not retroactively capture historical events.

Paragraph Summary

WorkOS announced that its Audit Logs feature now automatically records two types of events: sign-in sessions where users complete authentication through WorkOS, and membership changes when users are added to or removed from organizations. Previously developers had to manually call the Audit Logs API to record these actions; now it is done by default, reducing instrumentation costs for compliance scenarios such as SOC 2 and ISO 27001. However, automatic capture is limited to identity-layer events; business operations such as modifying configurations or accessing sensitive data still require active reporting from the application side. Another key limitation is that the feature is not retroactive: events that occurred before activation are not backfilled because WorkOS did not previously persist these events for audit purposes, and the audit time window starts from the moment of activation. The article recommends that teams relying on WorkOS confirm the feature toggle status as early as possible and check the ingestion configuration of downstream log systems such as SIEM.