Usage-based Auto-lock
Automatically lock Resource access for users who haven't accessed it within a configured duration to enforce least privilege.
Usage-based auto-lock requires users to periodically access a Resource to maintain access to it. If a user does not access the Resource within the configured duration, their access is automatically locked. This makes it easier to achieve least-privilege access by removing access for users who no longer need it.
Configuration
You can configure auto-lock from either a Resource or Group page. The auto-lock duration can be set to 1, 7, 30, 60, or 90 days through the Admin Console (other durations are available via the API). When a user has not accessed the Resource within the configured duration, they are locked out.
Regaining access depends on the approval method:
- Manual approval: An admin must unlock access for the user.
- Automatic approval: The user provides a reason for accessing the Resource, after which access is restored.
Changes to auto-lock settings appear in the Access category of the audit logs in the Admin Console.
From a Resource Page
The auto-lock duration can be configured directly on a Resource and applies to all users with access.
You can specify an auto-lock duration when adding a Group to a Resource. By default, a Group inherits the Resource-level configuration. The auto-lock duration applies to all users in the Group, but locking is evaluated per user.
You can also modify the auto-lock duration for a Group that already has access. Click the options button for that Group and set the duration and approval method.
From a Group Page
You can set an auto-lock duration and approval method for specific Resources on the Group’s detail page.
Unlocking Access
Admins can unlock a Resource for a user on the user’s detail page in the Admin Console.
Tracking Access
To see configuration details and the current status of users’ access, download a summary from the Resource, Group, or User page.
The report includes:
- Groups that have access to the Resource and the policy used for access
- Expiration dates (if configured)
- Auto-lock duration
- For individual users: whether they are currently locked and the last time an admin unlocked them (if applicable)
Requesting Access
If the policy requires manual approval, locked-out users can submit a request via the block page with a reason for access. An admin must approve the request before access is restored.
If the policy uses automatic approval, locked-out users provide a reason and access is restored immediately. The reason and access details are still recorded in analytics and on the resolved requests page.
Reviewing Access
Details are covered under Reviewing Access Requests.
Notifications
Admins can configure how they are notified of incoming requests under Settings > Notifications. Email notifications can be toggled on or off per user for any user with the Admin, DevOps, Support, or Access Reviewer role. Webhooks are also supported for integrating requests into an existing workflow.
An example webhook payload:
{ "timestamp": "2025-10-18T20:03:36.973121+00:00", "tenant": "autoco.twingate.com", "version": "1", "type": "ACCESS_REQUEST", "request_id": "QWNjZXNzUmaxdWazdDoyNTU=", "request_url": "https://autoco.twingate.com/access-requests?user_id=VXNlcjoxNDgaNT0x&access_request_id=aWNjZXNz0mVxdWVzdDoyNTU=", "user_name": "Alex Marshall", "user_url": "https://autoco.twingate.com/users/VXNlcjoxNag0NTUx", "resource_name": "Gitlab", "resource_url": "https://autoco.twingate.com/resources/UmVzb3VyY2U6NDA4N0c0MA==", "requested_at": "2025-10-18T20:03:36.745863+00:00", "reason": "I need access after a long period of no usage.", "approval_mode": "MANUAL", "request_type": "AutoLock", "request_duration_seconds": 2592000}When a request is approved or denied, users receive an email notification so they can continue working or follow up as needed.
Last updated 29 days ago