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.

Auto-lock duration configured at the Resource level, applying to all users with access
Auto-lock duration configured at the Resource level, applying 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.

Adding a Group to a Resource with an auto-lock duration specified for the Group's access
Adding a Group to a Resource with an auto-lock duration specified for the Group's access

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.

Modifying the auto-lock duration and approval method for a Group that already has access to a Resource
Modifying the auto-lock duration and approval method for a Group that already has access to a Resource

From a Group Page

You can set an auto-lock duration and approval method for specific Resources on the Group’s detail page.

Setting an auto-lock duration and approval method for a Resource on a Group's detail page
Setting an auto-lock duration and approval method for a Resource on a Group's detail page

Unlocking Access

Admins can unlock a Resource for a user on the user’s detail page in the Admin Console.

Unlocking a locked Resource for a user from the user's detail page in the Admin Console
Unlocking a locked Resource for a user from 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.

Downloading an access summary report from a Resource page
Downloading an access summary report from a Resource 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.

The block page that locked-out users see, where they can submit a request with a reason for access
The block page that locked-out users see, where they can submit a request with a reason for access

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.

Notification settings for access requests, including admin role filters and webhook configuration
Notification settings for access requests, including admin role filters and webhook configuration

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