Teams working under SOC 2, ISO 27001, or GDPR get asked the same questions at audit time: who had access to what, when, and who changed it. An identity layer that cannot answer those questions on its own turns every review into a scramble. This is a tour of the auditability and governance features WeftID supports out of the box, with nothing to bolt on, and, because you self-host, with the data never leaving your own infrastructure.
A complete, attributable event log
Every write operation in WeftID is recorded in the event log. Each event captures who performed the action, what it affected, when it happened, and the request context, including IP address and user agent. Sign-ins and sign-outs, password and passkey changes, group membership edits, identity provider and service provider configuration, SSO assertions issued, certificate rotations, SCIM activity: it all lands in one place.
Events are classified into four visibility tiers (security, admin, operational, and system) so a reviewer can start with the security and configuration changes that matter most, then widen to high-volume automated activity when they need the full picture. Filter by date range, event type, actor, or affected object, and open any event to read its full metadata. Administrative actions are logged the same as everything else, so the accounts with the most power leave the clearest trail.
Evidence you can hand to an auditor
A log you can read on screen is not the same as evidence you can submit, so WeftID produces both.
The event log exports to a password-encrypted XLSX file. The export resolves internal IDs to readable names (users, groups, applications, and identity providers appear next to their UUIDs), locks the cells against accidental edits, and runs as a background job so a wide date range never ties up your session.
For access reviews, the user export answers "who can reach what" in a single workbook: one sheet listing every user with role, status, authentication method, two-step status, and last sign-in; one sheet with a row per group membership; and one sheet with a row per user-to-application grant, including how that access is granted and when it was last used. That is the artifact a quarterly access review asks for, produced on demand.
Separation of duties
WeftID has three roles, and the boundaries sit where governance expects them. Standard users reach only their own dashboard and profile. Admins run day-to-day operations (users, groups, reactivation approvals) but cannot change security settings or touch identity provider configuration. Only super admins change authentication and session policy, manage identity providers, and perform irreversible actions like GDPR anonymization. There is always at least one super admin, and the last one cannot be deactivated or deleted.
Both admins and super admins can read the audit log, and every administrative change is itself an audited event, so privileged access never means unobserved access.
Strong authentication, enforced tenant-wide
For a tenant handling regulated data, optional MFA is not enough. WeftID's enhanced authentication policy drops email one-time codes as an acceptable second factor and requires every user to hold a TOTP authenticator or a passkey. Anyone not yet enrolled is redirected to enrollment on their next sign-in and cannot reach the dashboard, or complete an SSO assertion to a downstream app, until they finish.
Passwords are checked against the Have I Been Pwned breach database when set, using k-anonymity so the password itself never leaves your deployment, and a weekly background job re-checks every stored credential against newly disclosed breaches. A match forces a reset and revokes the user's API tokens. Sessions carry a configurable maximum lifetime, dormant accounts deactivate automatically after a threshold you set, and sign-in verification can be tightened to resist account enumeration.
The right to be forgotten, without losing the record
GDPR pulls in two directions: erase personal data on request, but keep proof of what happened. WeftID's anonymization does both. It is irreversible and limited to super admins. It replaces the user's name, scrubs every email address, deletes all two-step verification material, and clears the password, while preserving the user's ID and audit trail. The person is erased; the record that they once held access, and when it was removed, survives for compliance.
Short of erasure, deactivation cuts off access at once: the session is terminated and OAuth2 tokens are revoked the moment a user is deactivated. Reactivation runs through an approval workflow with its own decision history, so restoring access is itself a reviewable event.
Retention and residency you control
Because WeftID runs on your own infrastructure, the data lives where your compliance regime requires it and never transits a vendor's cloud. Tenant isolation is enforced in the database: the application connects through a restricted PostgreSQL role with row-level security, so cross-tenant access is architecturally impossible rather than merely checked in code. Secrets are encrypted at rest, and the whole system is MIT licensed, so your reviewers can read exactly what it does.
Retention is yours to set. SCIM sync history can be kept for 3, 6, 12, or 24 months, or forever for regulated tenants, and administrative audit events are retained regardless of that setting. The event log itself lives in your database, so its long-term retention follows the backup schedule you already run.
In short
A high-governance deployment needs four things from its identity layer: a complete record of what happened, evidence it can export, a clear line between who can do what, and certainty about where the data lives. WeftID provides all four out of the box, and leaves the data on infrastructure you control.
Read the audit guide for the full reference, view the source on GitHub, or try it out.