# Invite, change and remove access

URL: /security/manage-access

Add people to Foxborne, change their role, remove them and set the session policy, all from the Access page. Each change is recorded in the audit log with the admin who made it.



Membership usually arrives through SCIM from your identity provider. The **Access** page covers the rest: inviting someone, changing a role, removing access at once and setting how long a session lasts.

## Before you start [#before-you-start]

* You need the **Admin** role. Only admins hold **Manage hosting, keys and access**.
* [Single sign-on](/security/sso) is in place. Invited people sign in through your identity provider.

## The Members table [#the-members-table]

Go to **Access**. The **Members** tab lists everyone with access.

| Column      | What it shows                                                                                                         |
| ----------- | --------------------------------------------------------------------------------------------------------------------- |
| Person      | Avatar, name and job title                                                                                            |
| Email       | The person's work email                                                                                               |
| Role        | One of the five roles                                                                                                 |
| Sign-in     | **Single sign-on**, or **Local, hardware key** for the break-glass account, which also carries a **Break-glass** chip |
| Two-factor  | **On**, or **Pending first sign-in**                                                                                  |
| US person   | **Asserted** or **Not asserted**, as your identity provider reports it                                                |
| Last active | A relative time, or an **Invited** chip                                                                               |

Each row ends with an actions button that opens **Change role** and **Remove access**. The note under the table reads: **Removing someone in the identity provider removes them here within five minutes. US person status comes from the identity provider and gates evidence marked EXPT.**

## Invite someone [#invite-someone]

<Steps>
  <Step title="Open the invite dialog">
    Select **Invite**, at the top of every tab on **Access**. The **Invite someone** dialog opens.
  </Step>

  <Step title="Enter the email and role">
    Enter the person's **Work email** and choose their **Role**. The list holds the five roles and starts at **Investigator**.
  </Step>

  <Step title="Send the invitation">
    Select **Send invitation**. The console confirms **Invitation sent to** and the address. The audit log records **Invited user**, with the address as the object and the role as the detail.
  </Step>
</Steps>

An address that is not a valid email gets a red outline, and the dialog stays open. The invited person appears with an **Invited** chip under **Last active** and **Pending first sign-in** under **Two-factor**. Both change once they sign in through your identity provider.

With SCIM on, adding someone to a Foxborne group in the identity provider works as well. See [SCIM provisioning](/security/scim).

## Change a role [#change-a-role]

<Steps>
  <Step title="Open Change role">
    On **Members**, open the person's actions and choose **Change role**. The dialog **Change role for** and their name opens, with the note &#x2A;*Takes effect on their next request.**
  </Step>

  <Step title="Pick the new role">
    Select one of the five role cards. Each card shows the role's name and description, as [Roles and permissions](/security/roles) lists them.
  </Step>

  <Step title="Save">
    Select **Save**. The console confirms the person's new role, and the audit log records **Changed role** with the person and the role. If you pick the role they already hold, the dialog closes and nothing changes.
  </Step>
</Steps>

## Remove access [#remove-access]

<Steps>
  <Step title="Open Remove access">
    On **Members**, open the person's actions and choose **Remove access**.
  </Step>

  <Step title="Read the confirmation">
    The dialog asks **Remove** and the person's name. It explains: &#x2A;*They lose access at once. Their notes, edits and audit entries stay, attributed to them.**
  </Step>

  <Step title="Confirm">
    Select the red **Remove access** button. The console confirms the removal, and the audit log records **Removed user** with the detail **Access revoked**.
  </Step>
</Steps>

With SCIM on, remove the person in your identity provider as well, so the two lists agree.

## Set the session policy [#set-the-session-policy]

The **Sessions** panel on the **Sign-in** tab holds the session policy.

| Setting             | Example value                | Choices in the dialog                          |
| ------------------- | ---------------------------- | ---------------------------------------------- |
| **Idle timeout**    | 30 minutes                   | 15 minutes, 30 minutes or 1 hour               |
| **Longest session** | 12 hours                     | 8 hours, 12 hours or 24 hours                  |
| **Two-factor**      | Required for everyone        | Not in the dialog                              |
| **Networks**        | 10.0.0.0/8 and the VPN range | **Allowed networks**, a list of address ranges |

<Steps>
  <Step title="Open the session policy">
    Select **Edit** on **Sessions**. The **Session policy** dialog opens.
  </Step>

  <Step title="Choose the limits">
    Choose the **Idle timeout** and the **Longest session**. List the **Allowed networks** as address ranges separated by commas, such as `10.0.0.0/8, 172.20.0.0/16`.
  </Step>

  <Step title="Save">
    Select **Save**. The console confirms **Session policy saved**. The audit log records **Changed session policy** on **Access**, with a detail such as **30 minutes idle, 12 hours max**.
  </Step>
</Steps>

Two-factor is required for everyone, and the dialog has no setting for it.

## Break-glass access [#break-glass-access]

The **Break-glass access** panel on the **Sign-in** tab names the local account kept for when the identity provider is down. Its two rules are fixed:

* **Every break-glass sign-in is audited and raises an alert in your SIEM.**
* **Requires a hardware security key. Passwords alone are refused.**

[Break-glass access](/security/sso#break-glass-access) on the single sign-on page shows how the account signs in.

## Check the result [#check-the-result]

* **Members** shows the new person, the new role or the removal.
* The audit log's **Administration** filter lists the **Invited user**, **Changed role**, **Removed user** and **Changed session policy** entries, each with the admin who made it.
* The **Sessions** panel shows the new **Idle timeout** and **Longest session**.

## Troubleshoot [#troubleshoot]

**The invite dialog stays open.** The **Work email** field has a red outline because the address is not a valid email. Correct it and select **Send invitation** again.

**An invited person still shows Invited.** They have not signed in yet. **Two-factor** reads **Pending first sign-in** until they do.

**Someone cannot open export-controlled evidence.** Their **US person** column reads **Not asserted**. The status comes from the identity provider, not from this page: see [Export-controlled evidence](/security/export-control).

**The identity provider is down.** Sign in with the break-glass account and its hardware security key, as [Single sign-on](/security/sso#break-glass-access) describes.

## Next [#next]

* [Roles and permissions](/security/roles) lists what each role may do.
* [SCIM provisioning](/security/scim) moves membership into your identity provider's groups.
* [Audit log](/security/audit-log) shows every access change and who made it.