Docs
Open Moduvio
Operations & governance

1. Tenant access, MFA, users and roles

Prove platform/tenant separation, host-resolved company routing, credentials-first TOTP or one-time recovery authentication, credential recovery, clearance, site scope and least-privilege access before inventory testing.

Purpose

Prove platform/tenant separation, host-resolved company routing, credentials-first TOTP or one-time recovery authentication, credential recovery, clearance, site scope and least-privilege access before inventory testing.

Roles

Platform Administrator, Tenant Administrator, then every named user

Example

Aarav Rao — Stores Officer; Nisha Iyer — Quality Inspector; Kabir Sen — Stores Supervisor; Meera Shah — Materials Planner; Vikram Das — Security & Compliance Officer.

Before you begin

  • Platform Administrator is enrolled
  • Comrado Aerospace tenant is active
  • One company administrator account and one controlled test site exist

User provisioning fields

Display name

The person’s recognisable name used in screens and attributable audit history.

Username / email

The unique sign-in identifier inside this company deployment.

Initial password

A temporary credential given only to the named user. TOTP setup follows successful password verification on first login.

Assigned roles

Defines the practical company functions a person performs. Moduvio expands them into controlled workflow authorities; review the mapping on Company roles.

Assigned sites

Defines where the user can act. Permission in one site never opens records in an unassigned site.

Clearance

The highest record classification the user may view: UNCLASSIFIED < RESTRICTED < CONFIDENTIAL < SECRET. It is a visibility ceiling—not a job level—and does not grant an action by itself.

Procedure

  1. 1

    As Platform Administrator, verify that Comrado and its first company administrator are managed without tenant inventory access.

  2. 2

    Open the Comrado deployment and confirm there is no organisation field; enter company-admin credentials, then confirm the QR/manual TOTP setup appears only after the password step succeeds.

  3. 3

    Scan the QR code in the user's authenticator, enter the generated code, save the one-time recovery codes, and confirm company access is then granted.

  4. 4

    Provision each named user with one primary role, the test site and the minimum required clearance; give only the temporary password to that user.

  5. 5

    Have each user complete their own first-login TOTP enrollment and save their recovery codes.

  6. 6

    Use one recovery code to sign in; sign out and prove the same code cannot be reused.

  7. 7

    Open Account security, replace recovery codes and confirm every prior code and session is revoked.

  8. 8

    Change the password with current password + TOTP; confirm the old password and old session fail, then sign in with the new password.

  9. 9

    As administrator, reset a test user's MFA and confirm its old TOTP, recovery codes and sessions fail, then confirm the QR setup returns after the password step.

  10. 10

    Attempt one permitted and one forbidden page/API action for each role; disable a test user and confirm the next request is rejected.

Expected result

  • Correct password without a current TOTP or valid unused recovery code is rejected
  • TOTP secrets are encrypted and recovery codes are hashed at rest
  • Credential changes and administrator recovery revoke active sessions
  • Users see only assigned sites and classifications at or below clearance
  • Custom roles contain only controlled catalog permissions and API authorization enforces them
  • Maker–checker actions cannot be completed by the originating user
  • No shared operational account is required

Documentation version 2026.09

Last reviewed August 2026