There’s a class of security incident that MSPs feel more acutely than most: the one caused by their own tooling. A technician account with no MFA. A contractor who left six months ago but still has credentials to the documentation platform. A junior tech who was given admin access temporarily and never had it revoked. These aren’t theoretical — they’re the kind of thing that shows up in post-mortems after a breach.
Most documentation platforms handle access control as an afterthought. You get usernames, passwords, maybe optional MFA, and a role or two. Weavestream approaches it differently: MFA is mandatory, registration is invite-only, and access is controlled across three independent dimensions. There’s no way to create an account without completing MFA enrollment. There’s no “I’ll set up two-factor later.”
Why “Optional MFA” Is a Liability
When MFA is optional, it’s only a matter of time before someone skips it. A new technician sets up their account on a Friday afternoon and plans to configure the authenticator app Monday morning. A busy admin creates a service account for a vendor and forgets to enforce MFA. Optional controls create exceptions, and exceptions accumulate.
Weavestream removes the choice. Every account — technician, contractor, client user, admin — completes TOTP MFA enrollment as part of the account setup flow. The setup is sequential: set your password, then scan the QR code and confirm a code. You can’t skip past it. You can’t log in until it’s done.
This matters specifically for MSPs because your documentation platform holds credentials, network documentation, and asset records for every client. That’s not a system where “most accounts have MFA” is an acceptable posture.
Invite-Only Registration
There is no public registration. No sign-up page. No way for anyone to create an account without a SUPER_ADMIN initiating it first.
When a new technician joins your team, an admin creates the account, which generates a one-time setup token delivered as a URL. The technician opens the link, sets their display name and password, enrolls their authenticator, and they’re in. Setup tokens are time-limited and single-use — if the token expires unused, the account sits inert until a new one is generated.
This eliminates an entire category of risk: unauthorized self-registration, credential stuffing against a sign-up endpoint, and accounts that were created for trial access and never cleaned up.
Three-Axis RBAC
Access control in Weavestream isn’t a single permission level. It’s three independent axes that combine to determine what any given user can actually do.
Global role is the broadest. SUPER_ADMIN has implicit full access everywhere. OPERATOR is the standard staff role — tenant access is then governed by the other two axes. CONTRACTOR is for external parties and gets per-tenant access only, always with an expiration date. CLIENT_USER is read-only, for client contacts accessing their own tenant portal.
Per-tenant memberships control what a user can do in each specific client workspace. A membership can be FULL (read and write) or READONLY. A technician can have FULL access to some client tenants and READONLY on others. This is the right model for MSPs where different technicians own different client relationships.
Default tenant access (globalAccess) fills the gaps for Operators. It determines what happens when an Operator encounters a tenant they have no explicit membership for — full access, read-only, or no access. This is especially useful for principals or senior staff who need to be able to see any client on demand, without being manually added to every tenant as clients are onboarded.
The combination gives you real granularity. A senior tech gets globalAccess: READONLY so they can always pull up any client record, with explicit FULL memberships on their assigned accounts. A junior tech gets globalAccess: NONE and only sees the tenants they’ve been explicitly granted. A specialist brought in for a specific project gets a CONTRACTOR account with a membership to one tenant.
Platform Capabilities Keep Admin Functions Separate
Tenant access governs what you can see and do within client workspaces. Platform capabilities govern what you can do to the platform itself — creating tenants, managing users, configuring integrations, running backups, reading the global audit log.
These are handled separately via a capability list assigned to each account. A technician can have FULL access to every client tenant and still not be able to create new users or trigger a backup export. SUPER_ADMIN gets all capabilities implicitly; everyone else gets exactly the capabilities assigned to them.
This separation matters operationally. You don’t need to give a technician admin-level platform access just because they need to do technical work across multiple clients.
Contractor Access With Automatic Expiry
Third-party access is one of the harder problems in MSP security. You bring in a vendor for a project. You give them access to the relevant client workspace. The project ends. Do you remember to revoke the access? Usually not immediately.
Weavestream’s CONTRACTOR role addresses this structurally. Contractor memberships require an expiresAt timestamp — you can’t create one without setting an expiration. When the timestamp passes, the account is locked out immediately. No grace period. No lingering access. The next API call from that contractor’s session is rejected.
You still need to set a sensible expiration when you create the account. But the system enforces it automatically once set, which is better than relying on a manual revocation task that may or may not happen.
Session Management and Rate Limiting
Login security extends past MFA enrollment. Each login creates a server-side session record with IP address, user-agent, and timestamps. Access tokens are JWTs with a 15-minute lifetime. Session revocation is immediate — when a session is revoked (by the user or by a SUPER_ADMIN), the next API request using that session’s token is rejected, without waiting for the JWT to expire.
The login endpoint has two independent brute-force protections: a per-IP and per-email rate limit (5 attempts per minute by default) and an account soft-lock after 5 failures in a 15-minute window. When the soft-lock triggers, it can only be cleared by waiting out the window or by a SUPER_ADMIN. Error responses don’t reveal whether a given account exists, which prevents user enumeration.
The Self-Hosted Security Argument
Cloud-based documentation platforms make a reasonable argument that they handle security so you don’t have to. The counter-argument is that they also centralize the risk: one breach at a SaaS provider can expose data from every MSP on the platform.
Self-hosted doesn’t automatically mean more secure — it depends entirely on how well you run the infrastructure. But it does mean your client data isn’t co-mingled with tens of thousands of other MSPs on shared infrastructure. The attack surface is your server, not a hyperscaler target that’s worth breaching specifically because it holds so many clients’ credentials.
Weavestream’s access control model — forced MFA, invite-only registration, three-axis RBAC, contractor expiry, immediate session revocation — gives you the tools to run a tight ship. Whether that’s more or less secure than your current SaaS arrangement depends on your specific situation, but it at least means the controls are in your hands.
Weavestream is free, self-hosted, and open source. If you’re evaluating your MSP tooling stack or looking for a documentation platform that takes access control seriously, explore it at weavestream.io.