> ## Documentation Index
> Fetch the complete documentation index at: https://docs.weelkit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Organization security

> Require two-factor authentication, bind sign-in to your company domain, set session and password rules, restrict IP addresses, and review the audit log.

Admins open **Organization settings → Security**. Saving any change here asks you to [confirm it's you](https://docs.weelkit.com/settings/account-security.md#confirm-your-identity).

## Two-factor authentication

Under **Two-Factor Authentication**, turn on **Enable 2FA** to require an authenticator app by role. In **Enforcement by Role**, set each role to **Required** or **Optional**. A role you haven't set counts as required.

Set the **Grace period**: how long members get to set it up when their role becomes required: none (required at once), 3, 7, 14 or 30 days. The default is 7 days. Members in that role who haven't set it up see a banner with the deadline; after it, Weelkit routes them to set it up before they can continue. Google or GitHub sign-in doesn't satisfy the requirement on its own: members need Weelkit's authenticator code.

## Company-domain sign-in

Under **Company Sign-In**, make members sign in with an account from your company:

1. Under **Approved email domains**, add your domains, for example `example.com`.
2. Turn on **Require Google or GitHub sign-in with your company domain**, and under **Applies to** choose **All members** or **All members except admins**.

Then a Google sign-in must come from a Google Workspace account on an approved domain, and a GitHub sign-in must have a verified primary email on an approved domain. Personal Google or GitHub accounts are refused, and the person is told why. A session signed in another way is asked to sign in again with a company account. When you invite someone whose address isn't on an approved domain, Weelkit warns you. To keep you from locking yourself out, Weelkit applies the rule only if your own current sign-in already meets it.

## Sessions

Under **Authentication & Sessions**:

* **Session Timeout:** hours of inactivity after which your organization asks the person to sign in again. It applies to your organization only; it never signs them out of their other organizations.
* **Remember Me Duration:** the longest a "Remember me" session can last, up to 90 days. If a member belongs to several organizations, the shortest duration applies.
* **Force Logout on Password Change:** signs a member out of all their other sessions when their password changes.

## Password requirements

These add to Weelkit's own rules (at least 8 characters, not found in known data breaches, not the current password):

* **Minimum Password Length**.
* **Require Uppercase Letter**, **Require Lowercase Letter**, **Require Number**, **Require Special Character**.
* **Password Expiration:** days before members must change their password; 0 turns expiration off. Members who sign in only with Google or GitHub have no password and are exempt.
* **Prevent Password Reuse:** how many previous passwords are blocked.

They apply when members sign up from an invitation, reset their password or change it. A member of several organizations gets the strictest rules.

## IP allowlist

Under **Network Access Control**, turn on **Enable IP Restrictions** and list the allowed addresses, one IPv4 address, IPv6 address or CIDR range per line. Requests to your organization from anywhere else are refused. Weelkit checks the address the request really came from, even behind proxies.

> [!NOTE]
>
> Weelkit turns restrictions on only if your current address is in the list, so you can't lock yourself out.

## Alerts and audit log

Under **Audit & Compliance**:

* **Log Retention Period:** how long audit entries are kept.
* **Suspicious Activity Detection:** flags 5 or more failed sign-ins to a member's account within 15 minutes. It's recorded in the audit log, and the alert goes to that member and your organization's owners and security admins.
* **Real-Time Security Alerts:** also email the **Alert Email** as soon as suspicious activity is detected.

The audit log shows who did what and when: sign-ins, two-factor changes, session revocations, members leaving, policy denials and settings changes. Each entry shows the action in plain words, who performed it and their role, the time, the affected area, and their device and location. Search by person, and filter by action type, user and date range. Under **Export Audit Logs**, choose **Export current filters** for a CSV of the entries you're looking at.

## Members' security

In [Team and roles](https://docs.weelkit.com/settings/team-and-roles.md#members), admins see each member's two-factor status and when they were last active, and can choose **View sessions** to review and sign out a member's sessions.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.