Security settings

Settings → Security holds the organization-wide choices about how people sign in and what Flowtly records when they do. The settings here apply to everyone in the organization, whatever an individual has chosen for their own account.

There are no password policies and no session timeouts on this page, or anywhere else in Flowtly.

Who can change these

Anyone in the organization can open the page, but only an administrator can change the settings on it. If you are not an administrator, the controls you cannot change are not shown to you at all.

Require multi-factor authentication

Requires everyone in the organization to sign in with a second factor. A member who has not set up an authenticator yet is taken through setup on the sign-in screen rather than being refused, so switching this on locks nobody out.

Multi-factor authentication covers setup, recovery codes and trusted devices in full.

Turn off email sign-in codes

Removes the Email option from the sign-in screen, so a second factor can only come from an authenticator app or a recovery code. Email codes are only as safe as the mailbox behind them, which is why an organization may prefer not to allow them.

When this is on it applies to everyone, whatever an individual has chosen for their own account.

Log full IP addresses on sign-in

Controls how much of a person's IP address Flowtly keeps in the record of their sign-in.

Off — the default — stores only the network prefix: the first three parts of an IPv4 address, or the first four groups of an IPv6 one. That is enough to tell an office from a home connection, or one country from another, without identifying a single connection.

On stores the complete address of everyone who signs in.

Two things are worth knowing before switching it on:

• What is captured is kept indefinitely. There is no automatic deletion of sign-in records, so a full address recorded today stays recorded.
• It only affects sign-ins tied to an organization. A sign-in attempt that Flowtly cannot attribute to an organization — a failed one against an address that is not a member, for instance — always keeps the prefix only, whatever this setting says.

Because the full address identifies a connection rather than a network, turning it on is a privacy decision as much as a security one. It is the right choice when you need to investigate individual sign-ins precisely — tracing a suspicious access to a specific machine, or answering an auditor who asks exactly where a session came from. Where no such need exists, the prefix answers the usual questions and keeps less.

Changing the setting applies from that moment on. Records already written keep whatever detail they were written with: switching it on does not fill in addresses that were stored as prefixes, and switching it off does not shorten addresses already stored in full.

Example use cases

• An administrator meeting a client's security requirement turns on the organization-wide MFA requirement in one place, without asking anyone to act first.
• An organization that treats a mailbox as too weak a second factor turns off email sign-in codes, leaving authenticator apps and recovery codes.
• A regulated team turns on full IP logging ahead of an audit that asks precisely where each session originated.
• An administrator investigating a suspicious sign-in checks whether full addresses were being recorded at the time, and finds a network prefix rather than a specific connection.