1. Shared infrastructure requires explicit boundaries
Multi-tenancy means a service supports multiple customer organisations within a shared software environment. Sharing infrastructure does not mean customers should share access to information. The security objective is to keep each tenant's records and operations within the appropriate boundary while allowing authorised collaboration inside that tenant.
A boundary failure can expose information or allow changes in the wrong organisation. Evaluation should therefore cover ordinary screens, searches, exports, integrations and background processing, rather than treating tenant isolation as a property of the interface alone. Different services implement isolation differently; no single architecture label proves security.
- Identify which organisation owns each record and which context governs an action.
- Ask how tenant restrictions apply across the service, not just at sign-in.
2. Authentication is not authorisation
Authentication establishes who a user is. Authorisation determines what that user may do in a particular organisation. A successful login must not by itself grant access to every tenant or every administrative function. Membership and role checks need to apply to the requested operation and its target.
Lojycal has tenant-scoped access controls, organisation membership and role restrictions, and MFA/passkey capabilities. These are relevant controls, not an absolute security guarantee. Confirm the available configuration and applicable requirements for your plan and workspace.
- Map roles to necessary tasks, including viewing, editing, approving and exporting.
- Review access when responsibilities change rather than relying only on account creation checks.
3. Limit administrative and integration privileges
Administrative privileges deserve separate scrutiny because they can affect many users or records. Ask how customer administration, provider support access and integration credentials are governed. Review approval, revocation and monitoring arrangements without assuming that every administrator needs unrestricted access.
A connected provider also creates a permission boundary. Credentials and provider scopes influence what an integration can read or change. A connection that works for one action does not establish authority for another, and a configured integration should not be interpreted as universal enforcement.
- Use the narrowest practical role and provider permissions for the intended operation.
- Request current information about administrative access arrangements and responsibility for credential changes.
4. Make cross-boundary mistakes testable
Security testing should include negative cases: attempts that must be denied, not just actions that should succeed. A fictional evaluation might create two authorised test organisations with synthetic records, then check that a user belonging only to one cannot retrieve or modify the other's records through supported interfaces.
Such testing requires explicit permission, agreed scope and non-production data. Do not probe other customers or attempt to bypass controls. Lojycal's tenant controls do not by themselves prove MSP cross-customer management or any particular independent testing result.
- Include removed memberships, reduced roles and exports in the agreed evaluation.
- Request relevant assurance evidence and clarify its scope and date.
5. Use auditability to support investigation
Useful audit information helps reviewers establish who acted, in which organisational context, and with what outcome. Audit access also needs restrictions because logs and exported evidence can contain sensitive information. Logging alone neither prevents misuse nor proves every operation was captured.
Lojycal includes append-only audit and signed evidence export mechanisms. These support review and integrity checks; not all records are immutable, and these mechanisms are not certifications or legal guarantees. Confirm which events are recorded and which evidence can be reviewed for your intended use.
- Walk through how an authorised reviewer would investigate an unexpected permission change.
6. Treat configuration as an ongoing responsibility
Secure operation depends on configuration as well as platform capabilities. Maintain a role owner, review memberships, protect authentication methods and remove unnecessary integration permissions. Reassess settings when teams, providers or operating models change.
Use /trust as an evaluation starting point and discuss unresolved questions through /contact. Confirm current administrative practices, contractual arrangements and relevant assurance information with the team. Choose a platform based on demonstrated controls and your operating requirements, not an assumption that shared infrastructure is either inherently safe or inherently unsafe.
- Document accepted risks, outstanding questions and the person responsible for each follow-up.