Usage-based auto-lock allows you to require users to periodically access a Resource in order to maintain access to it. This is helpful to automatically remove access for users who may no longer need it based on their access frequency.

Usage-based auto-lock with Twingate

You can configure usage-based auto-lock from either a Resource or Group page. The auto-lock duration for a particular access right can be set at 30, 60, or 90 days through the Admin Console (with other durations possible when set via API). If a user has not accessed a Resource within that duration, that user will be locked out from accessing that Resource until they are unlocked by an admin.

Changes made to auto-lock duration will appear in the Access category of the Audit Logs reporting available within the Admin Console.

Implementing Usage-based Auto-Lock via a Resource Page:

The auto-lock duration can be configured on a Resource directly and will be applied to all users who have access to the Resource.

You can specify an auto-lock duration when first adding a Group to a Resource. By default, a Group will inherit what’s configured at the Resource level. The auto-lock duration will apply to all users in a group, but auto-locking will be applied on a per user basis.

An auto-lock duration can also be modified for a Group that already has access to a Resource by clicking on the options button for that Group and then setting the applicable expiration time.

Implementing Usage-based Auto-lock via a Group Page:

You can set an auto-lock duration for specific Resources that a Group has access to on the relevant Group page.

Unlocking Access

Admins can unlock a Resource for a user on a specific user’s detail page.

Tracking Access

To see the details of a Policy configuration and the current status of a user’s access, you can download a summary from the Resource, Group, or User page.

The information provided by a report includes:

• Groups that have access to the Resource and the Policy they use to access the Resource
• Expiration dates (if configured)
• Auto-lock duration configured
• For users, if they’re currently locked and the last time they were unlocked by an admin (if applicable)

Requesting Access

Users who are locked out from accessing a Resource can submit a request to regain access via the block page, providing a reason that can be reviewed by the Network’s admins.

Admins can review open requests on the Admin Console on the user page or Resource page.

If there are open requests, admins can also view them via the bell notification icon in the upper right-hand corner. This will take the admin to the Requests page, where they can view all open requests across all Resources. Admins, DevOps admins, and Access Reviewer roles have access to approve requests.

Admins can choose how they want to be notified of incoming requests via the Settings page. In Access Requests, they can choose which Admin roles are emailed when a request comes in (Admins, DevOps, or Access Reviewers). They can also choose to disable all notifications and instead set up a webhook to integrate these requests into an existing workflow.

An example payload of the webhook is below:

{
  "version": "1",
  "type": "ACCESS_REQUEST",
  "request_id": "ABC",
  "request_url": "https://acme.twingate.com/access-requests?user_id=123&access_request_id=ABC",
  "user_name": "John Doe",
  "user_url": "https://acme.twingate.com/users/123",
  "resource_name": "Gitlab",
  "resource_url": "https://acme.twingate.com/resources/XYZ",
  "requested_at": "2024-04-15T04:02:28.359054+00:00",
  "reason": "This is a test access request."
}

When a request is approved or denied, users will receive an email notifying them of the outcome so that they can continue working or follow up as needed.