Set your security baseline
Chapter 5 · about 5 minutes to read
This is the final chapter of Stage 1. You have an account, a verified email, a team, and a tidy profile. The last setup task is choosing how strict Zyra should be about who gets in, how long they stay, and what gets recorded.
Time: about 5 minutes, plus 5 more if you pick Custom. Prerequisites: rough idea of your compliance requirements (SOC 2, ISO 27001, PCI, internal policy).
Where to find it
Open Settings → Security → Baseline policy from the left sidebar. The page shows three preset cards and a fourth "Custom" option.
Pick the right baseline
Use this decision tree:
- Are you in a regulated industry (healthcare, finance, government) or do you handle customer PII? → choose Strict.
- Do you have a compliance program (SOC 2, ISO 27001) but evaluating Zyra in a sandbox? → start with Standard, switch to Strict before production.
- None of the above and you want sensible defaults? → Standard is fine. You can tighten any time.
- Need to mix and match (for example, strict session timeouts but optional 2FA during a 30-day pilot)? → Custom.
Standard baseline (recommended default)
The "good defaults" choice. Suitable for most teams evaluating Zyra and for production workloads that don't touch regulated data.
| Control | Standard setting | What it means |
|---|---|---|
| Single sign-on | Encouraged, not enforced | SAML/OIDC available; password login still allowed alongside |
| Two-factor authentication | Optional per user | Each member can enable TOTP from their profile |
| Session timeout | 24 hours | A signed-in session stays valid for 24 hours of inactivity |
| Audit log retention | 90 days | Every admin action stored and searchable for 90 days |
| IP allow-list | Off | Sign-in allowed from any IP your firewall permits |
| Password rotation | Not forced | Members rotate when they choose; no expiry enforced |
Strict baseline (regulated workloads)
The choice for SOC 2, ISO 27001, PCI, or internal policy that requires hardened controls.
| Control | Strict setting | What it means |
|---|---|---|
| Single sign-on | Required | SSO is the only sign-in method; password login disabled |
| Two-factor authentication | Required | TOTP enforced for every member; no exceptions |
| Session timeout | 8 hours | A session expires after 8 hours of inactivity; re-auth required |
| Audit log retention | 365 days | Full year of admin actions kept and exportable |
| IP allow-list | Available | Optionally restrict sign-in to a list of office or VPN ranges |
| Password rotation | 90 days | If passwords are used (rarely, since SSO is on) they rotate quarterly |
Custom baseline
If neither preset fits, click Custom and pick each control individually. The page shows every control with a short description and a dropdown of allowed values. There is no "advanced" tier hidden behind Enterprise — every control is available to every customer.
What each control actually means
- Single sign-on (SSO). When required, members sign in via your identity provider (Okta, Azure AD, Google Workspace, etc.) instead of a Zyra password. Setup is in Stage 4, chapter 5 of this guide.
- Two-factor authentication (2FA). A second proof of identity at sign-in, in addition to password or SSO. Zyra supports time-based one-time codes (TOTP) from apps like 1Password, Authy, or Google Authenticator.
- Session timeout. How long Zyra keeps you signed in before asking again. Shorter timeouts reduce risk from forgotten laptops; longer timeouts reduce friction. Tune to your team's tolerance.
- Audit log retention. How far back you can search administrative actions: invitations, role changes, device enrollments, billing changes, security setting changes. Longer retention costs nothing extra.
- IP allow-list. Restricts sign-in to a list of IP ranges (your office, your VPN exit, your CI runners). Adds a strong second perimeter; only enable once you're confident your team always connects from listed ranges.
Cost note
Every control listed is free on every plan. Strict baseline is not an Enterprise upsell. The split is by need, not by price.
How Zyra itself is secured
For evidence of Zyra's own posture — SOC 2, PCI SAQ A 89%, ASVS Level 1 91%, NIST CSF 2.7 self-score, ongoing SOC 2 audit — see getzyra.io/security. Your security team will want this as part of their vendor review.
Step — Save and confirm
Pick a baseline (or finish your custom picks), then click Apply baseline. Zyra shows a confirmation dialog summarizing what will change for current users — for example, "All members will be required to enroll 2FA at next sign-in." Confirm to apply.
Changes take effect immediately for new sign-ins. Members already signed in will be prompted to comply at the next session refresh.
What just happened
You have a security posture that matches your risk tolerance and a clear audit trail of who set what, when. Stage 1 is complete. Your organization is ready to receive its first Compute Node.
Troubleshooting
- A teammate is locked out after switching to Strict. They probably haven't enrolled 2FA. Any Organization Admin can issue a one-time bypass from Settings → Security → Member overrides so they can sign in and complete enrollment.
- SSO setup deferred. Standard baseline allows mixed auth; flip to Strict only after every member has linked their SSO account.
- Audit-log export needed for an external auditor. Settings → Security → Audit log → Export produces a signed JSON or CSV dump for any date range within your retention window.
Stage 1 is complete. Continue to Stage 2 — Your first successful deployment when you're ready to install the Compute Node agent. (Stage 2 chapters coming soon.)
Last reviewed: 2026-05-21