Policy and Audit

What an owner can enforce across a team, and what the audit trail will and will not tell you.

Team-wide inactivity timeout

A team owner can sign every member out after a period of inactivity. The control is in My Teams, inside the team, under Team Settings. Only the owner sees it: an admin can edit the team's name, domain and branding, but the inactivity cap is owner-only, and the API refuses it from anyone else.

The choices are No limit, 15 minutes, 30 minutes, 1 hour, 4 hours, 8 hours and 24 hours. There is no free-text value and nothing shorter than 15 minutes.

The cap covers everyone in the team, the owner included. The screen says so plainly:

Everyone in this team — including you as the owner — is automatically signed out after this much inactivity (or sooner, if someone sets a shorter personal timeout in their own account). "No limit" leaves it to each member.

Underneath, the owner is shown the number that will actually apply to them, because setting a 15-minute cap on the team sets a 15-minute cap on the person who set it.

How the effective timeout is worked out

Every member also has a personal setting in Profile & Account, on the Security tab, under Automatic Logout — the same durations, with No automatic logout in place of No limit. The timeout that applies is the shortest of:

• the member's own setting, and
• the tightest cap among every team they are a confirmed member of.

A pending invitation applies nothing; the cap starts biting once the invitation is accepted. Someone in two teams gets the tighter of the two caps. A member can always choose a shorter timeout than the team requires, and can never choose a longer one.

What enforcement does

Enforcement is server-side, on a sliding window. Every authenticated request restamps the last-activity marker; once the gap since the last one exceeds the timeout, the session is cleared and the request refused, and the app returns to the sign-in screen. Shortly before the cutoff the browser shows a Still there? dialog counting down, with Stay logged in and Log out now. After a cutoff the app reports Signed out — "You were signed out due to inactivity."

Requiring two-factor authentication

A team owner can require everyone in the team to have two-factor authentication on their CredenShare account. The control is in My Teams, inside the team, under Team Settings, in the Two-factor authentication box. Only the owner sees it, and the API refuses it from anyone else, admins included.

Tick Require two-factor authentication, choose when it Starts, and press Save. The choices are Immediately, In 3 days, In 7 days and In 14 days.

• It covers everyone in the team, the owner and admins included. Personal workspaces are not affected.
• What counts is the two-factor authentication described in Two-factor authentication: an authenticator app or email codes, either one.
• The owner needs it first. An owner without two-factor authentication cannot require it: the box says "Turn on two-factor authentication for your own account first." with a Turn it on link, and Save stays disabled.
• After saving, the box shows Required from and the date while the grace period runs, and Required since once it applies. Saving again does not restart the grace period. To turn the requirement off, untick it and save.

Members who sign in with Google

An account that signs in with Google only cannot turn on CredenShare's two-factor authentication. Ticking Accept Google sign-in as two-factor lets those members in on the strength of their Google account. As the box says, we cannot see whether their Google 2-Step Verification is on. It is unticked by default.

During the grace period

Members without two-factor authentication keep access. Across the app they see a banner reading "Team requires two-factor authentication from date. Turn it on before then to keep access to the team.", with a Turn it on button. The button opens the Security tab and, once a factor is on, offers a way back to the page they were on.

Once it applies

A member without two-factor authentication who opens the team lands on a page titled "Team requires two-factor authentication". It has two buttons:

• Turn on two-factor authentication opens the Security tab and brings them back to the team afterwards.
• Use my personal workspace leaves the team.

Until they turn it on, the team's shares, requests, settings and members are refused to them. Their personal workspace works as before. The team opens again as soon as they turn it on, with nobody needing to approve anything.

API keys that act in the team are covered too. A team key whose owner has no two-factor authentication is refused on the REST API with 403 and error code 143. On the MCP server it gets a tool error saying the key's owner has not turned it on. See Errors and limits.

Who has it on

Owners and admins see a 2FA column in the team's member list:

• On;
• Off;
• Google sign-in, for an account that signs in with Google only.

It shows whether a member has two-factor authentication, never which method. Members do not see the column.

IP access restrictions

Restricting a credential to known addresses requires the ip_access_restriction entitlement — Business and Enterprise. On any other plan the control is locked, and a request that carries an IP list anyway is refused server-side with a plan-upgrade error; see Errors and limits.

The restriction belongs to an individual share and is set under IP Whitelist when you create it. There is no organisation-wide allow list, and no team setting that applies one to every share a member creates.

• Add addresses one at a time. Single addresses (203.0.113.7) and CIDR ranges (203.0.113.0/24) are both accepted; a viewer passes on an exact match or on falling inside a listed range.
• Leaving the list empty skips IP gating entirely.
• The address compared is the recipient's own resolved client address, not the address of the CDN in front of us. The same value is what the access trail records.
• Share settings are fixed at creation. Addresses cannot be added to, or removed from, a share that already exists — create a replacement and expire the old one.

The IP check runs early: after the key carried in the link is verified, and ahead of expiry, login and passwords. A blocked recipient sees:

You don't have permission to access this share

That is deliberately the same wording a domain refusal produces, so the person on the other end learns nothing about which rule stopped them.

Access-log retention

How far back the trail can be read is set by your plan's max_days_access_logs entitlement.

Yearly plans carry the same window as their monthly equivalent.

Retention is a read window, not a deletion schedule. Access-log rows are never removed — not when the window passes, not when a share expires, and not when a share is deleted. The window only clamps how far back a query may reach: the earliest readable moment is always now minus your plan's days, recalculated on every request.

Two consequences are worth planning around.

• Upgrading widens the window immediately, and it widens it over history you already have. Rows written while you were on the smaller plan become readable again as soon as they fall inside the larger window.
• Downgrading narrows it the same day. Older rows are not destroyed, they simply drop out of reach. Upgrading again brings them back.

Both the per-share Access History dialog and Export Audit Logs clamp their date pickers to the window, and the export re-applies the limit on the server, so widening the range by hand changes nothing. When the clamp bites, the export says so: "Your plan allows up to N days of audit retention. Earlier dates were skipped."

One export returns at most 50,000 rows. Hitting that cap marks the result (truncated) and asks you to narrow the range and run it again.

What the trail records

A row is written when a share is successfully opened, and when a wrong password is submitted against one. Each row carries the columns shown in Access History:

When any row on the page looks like a scanner or an automated client, Access History says how many, and suggests the Secure view prompt: it keeps the content, and the view, behind a click, which scanners rarely make. Both exports, CSV and JSON, carry the label as client_type (browser, scanner, automation or unknown) and client.

Both the per-share view and the account-wide export download as CSV or JSON.

Do not read the trail as a record of every attempt on a link. Nothing is written when an open is turned away by a gate that runs before the credential is served:

• refused by the IP allow list;
• refused because the share had expired, its view limit was already used up, or the link's key did not match;
• stopped at the login, multi-factor or domain gate;
• a password prompt that was displayed but never answered — only a submitted, wrong password is recorded.

Two further absences are worth stating outright. Secure requests write no access-log rows at all: opening a request link and submitting to it leave nothing in the trail, though the share each submission creates has a trail of its own once someone opens it. And there is no customer-visible log of administrative actions — creating, expiring or deleting a share, inviting or removing members, role changes and plan changes are not exposed anywhere in the product. Creation and expiry times appear in the Shares and Expired Shares lists; see Key concepts.

Access history is per-creator

The trail belongs to whoever created the share, and no role can read another member's trail. This is not a permission that can be granted:

• Access History on a single share is checked against that share's creator. Any other caller, member or admin or owner, is refused.
• Export Audit Logs returns only rows for shares owned by the account making the request.

The only way to obtain another member's access history is to ask them to open Access History or Export Audit Logs on their own account and send you the file. Support cannot retrieve it either — see Help and support.