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, making it easier to achieve least-privilege access.

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 1, 7, 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. Regaining access is dependent on the approval required: manual approval requires an admin to unlock access, and automatic approval requires that the user provide a reason for accessing that Resource.

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 and approval method.

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

You can set an auto-lock duration and approval method 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

If the policy is set to require manual approval, 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.

If the policy is set to require automatic approval, users who are locked out from accessing a Resource will be required to submit a reason, after which they can continue on to the Resource. The reason and access details will still be included in analytics and on the resolved requests page.

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. Resolved requests within the last 90 days will also be displayed. 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.