- What qlture is
- Multi-tenancy
- Access roles
- Authentication
- Provisioning your user base
- How this documentation is organized
- A quick roadmap
What qlture is
qlture is a B2B SaaS platform for information security and continuous education — focused on phishing awareness, data protection, compliance and human risk. It is made up of three pieces:
| Piece | What it is | Who uses it |
|---|---|---|
| API | The backend that powers everything | — |
| Web console | Managing campaigns, users and analytics | Managers (admins and managers) |
| Desktop agent | App installed on the collaborator’s computer | Collaborators |
Everything documented below describes how to set up the platform’s modules in the web console and how to connect your identity systems.
Multi-tenancy
Each customer is an isolated tenant. All data, whether users, campaigns, or reports, is segregated by tenant, and nothing leaks between organizations. You don’t have to do anything for this to work: isolation is enforced in the backend on every operation.
Access roles
The role defines what each person sees. Collaborators don't access the web console — they only use the desktop agent.
| Role | Access |
|---|---|
TENANT_ADMIN |
Full administration of the tenant: users, SSO, SCIM, campaigns, billing |
TENANT_MANAGER |
Area/HR management: creates campaigns and tracks analytics |
COLLABORATOR |
Desktop agent only; authenticates via email OTP |
Authentication
qlture works with two tokens:
- The access token is short-lived (15 min) and travels on every request.
- The refresh token is long-lived (7 days on web, 30 days on the agent) and renews the access token without a new login.
In the web console the refresh token lives in an HttpOnly cookie, so the browser handles it. On the desktop agent, it is stored in an encrypted file on the device.
flowchart LR
U([User]) --> S{Surface}
S -->|Web console| W["Email + password<br/>or SSO"]
S -->|Desktop agent| A["Email OTP"]
W --> T["Access token 15 min<br/>Refresh in HttpOnly cookie"]
A --> D["Access token<br/>Refresh on the device"]
T --> API[("qlture API")]
D --> API
classDef hl fill:#c6ff00,stroke:#c6ff00,color:#070a0e;
class API hl
How each surface signs in
- Managers (web): email + password, or SSO (OIDC) if configured. See SSO.
- Collaborators (agent): they enter their email, receive an OTP code and the agent registers the device.
Revoking sessions
Every password change, logout or user deactivation invalidates all of that person’s active refresh tokens immediately, without waiting for the token to expire.
Provisioning your user base
You have three paths, from most manual to most automatic:
- Individual invite: the admin invites by email in the console.
- With self-enrollment, collaborators sign up on their own within rules you define (allowed domains, approval or OTP).
- SCIM synchronizes automatically from Entra ID, Google Workspace or Okta. This is the recommended path for mid-size and large companies. See SCIM provisioning.
How this documentation is organized
It follows the journey of someone administering the platform. Use the sidebar or start here:
| Section | For |
|---|---|
| Access and users | Getting people onto the platform: users, groups, SSO, SCIM and self-enrollment |
| Training and culture | Educating: content library, campaigns, learning paths and Security Champions |
| Phishing and defense | Testing and defending: simulations (email, QR, SMS) and PhishER triage |
| Communication and reports | Announcements and the collaborator reporting channel |
| Analytics | Measuring: dashboard, human risk, executive report and audit log |
| Collaborator portal | The other side — what the collaborator sees and does |
A quick roadmap
- Provision users — invite, import or automate with SCIM / self-enrollment.
- Connect manager login to your IdP with SSO.
- Publish a training — build a piece of content in the library and distribute it through a campaign.
- Run a phishing simulation to measure behavior — see Phishing simulation.
- Track human risk and let automation enroll those who need it into remediation.
</content>
