Skip to content
NebverseHRMS
All resources

Security

What multi-tenant HRMS security should mean in practice

A plain-language guide to tenant boundaries, server-derived access, operator controls, sessions and audit evidence.

8 minute read · Nebverse field guide
01

Tenant identity must come from the session

The browser should not be able to choose a tenant or role for a sensitive request. The server resolves both from an authenticated session and checks the target record against that scope.

  • Do not trust tenant IDs from forms
  • Use composite tenant keys where appropriate
  • Test cross-tenant denial explicitly
02

Platform access is a different boundary

A vendor superadmin has broader visibility than any customer user. It needs separate credentials, sessions, reasons for mutation and a durable audit trail. Silent impersonation weakens accountability.

  • Use a distinct platform cookie and principal
  • Force initial credential change
  • Keep support access explicit and time-bound
03

Operational proof matters

Healthy containers are not enough. Readiness should include the dependencies used by login, and release checks should cover session invalidation, origin protection and real browser behaviour.

  • Test idle and absolute expiry
  • Verify lockout and session revocation
  • Rehearse backup restoration
Use this as an operating guide

Adapt the checklist to your policies, legal advice, workforce and implementation scope. A product demonstration should prove the representative workflows you identify here.

Apply the guide to Nebverse

Use one working session to turn decisions into scope.

Bring your current workflow and identify what is configuration, migration, integration or policy work.

Book a working session Review plans