Authentication & Session Security
BYOVault issues two distinct families of session token — one for operators (the people running the backup product) and one for end users (employees using the self-service restore portal). The two are not variants of the same mechanism. They are checked separately, tracked separately, and cannot be substituted for one another.
Operator sessions
An operator authenticates with a password or via Microsoft SSO (an organizational Microsoft account). Either path issues the same kind of session token, uniquely tied to a server-side session record.
The session token carries an absolute expiry of 8 hours from issuance. This is a hard ceiling: no activity extends it, and once it passes, the caller must sign in again.
Idle timeout and revocation
An unexpired session token is not, by itself, sufficient to authenticate a request. Every request is also checked against its corresponding server-side session record, and each successful request updates that session’s last-active timestamp.
The request is rejected, and the caller must sign in again, if either of the following is true — independent of how much absolute time remains before the token’s 8-hour expiry:
- the session has been revoked, or
- the time since the session’s last recorded activity exceeds the account’s configured idle timeout.
The idle timeout is configurable per account, between 5 and 120 minutes, defaulting to 30. An account owner can view and change this value from account session-policy settings, and can list that account’s own active (non-revoked, non-idle-expired) sessions.
Signing out calls a real server-side revocation action: it marks the session as revoked, and every subsequent request against that token will now fail, regardless of how much of the token’s 8-hour window remains.
A token that is never explicitly signed out of remains usable, subject to the idle timeout above, until it reaches its absolute 8-hour expiry.
| Property | Operator session |
|---|---|
| Absolute token expiry | 8 hours from issuance, fixed |
| Idle timeout | Configurable per account, 5–120 minutes (default 30) |
| Revocation | Explicit sign-out, or session marked revoked server-side |
End users are a separate trust domain
The self-service restore portal (see Self-Service Portal) is used by employees of a client organization, not by BYOVault operators. These two populations are kept cryptographically distinguishable, not merely separated by convention.
An operator’s own valid, unexpired session is refused by every self-service route, and an end-user session is refused by every operator route. The two are mutually exclusive and cannot be substituted for one another.
End users authenticate through their own organization’s Microsoft Entra ID, not a BYOVault password. Sign-in is a delegated sign-in flow against the client tenant’s own Entra ID.
BYOVault verifies that the sign-in belongs to the specific Microsoft tenant already connected for that client, and identifies the person by a permanent Entra identifier, not the user’s sign-in name, which can change.
End-user idle timeout
End-user sessions are tracked entirely separately from operator sessions, so that revoking every end-user session for a client (for example, during offboarding) never touches an operator’s session.
The idle timeout enforced on end-user sessions is a fixed 30 minutes. Unlike the operator idle timeout, this value is not configurable per tenant or per account in the current release.
Tenant isolation for self-service
An end user signed in to the self-service portal can only ever see items belonging to their own organization, and within it, only the items they are entitled to. This boundary is enforced independently of which portal screen is in use: a request that does not resolve to a known user in a known tenant returns nothing at all, rather than falling back to a broader result.
Self-service access is also confined to the specific data the portal needs; it cannot reach unrelated application data.
What this means in practice
- An operator credential, however obtained, cannot be used to authenticate to the self-service portal, and the reverse is equally true.
- Revoking a client’s end users’ sessions in bulk (offboarding) never revokes or otherwise affects any operator’s own session.
- Self-service data visibility is enforced as a hard boundary that no individual portal screen can widen.