Security

Design Philosophy

niyase provides the same level of security regardless of scale. We do not build "cheap plans with weaker security." We operate at the level of audit standards such as SOC 2 Type II (certification in preparation).

Data Encryption

Location	Encryption
Desktop DB	Spaces of a cloud account are stored encrypted with a per-space key issued by the server. The key for opening them offline is kept in the OS secure storage. Spaces of a local account are not encrypted and are protected by the device and its OS login
Mobile DB	SQLCipher (a key issued by the server for spaces of a cloud account, a device key for a local account)
Cloud DB and its backups	Encryption at rest (Cloud SQL)
Desktop backup (ZIP)	Not encrypted. You manage the saved ZIP
Communication	TLS 1.3

Sensitive information (My Number, payroll bank accounts, pay amounts, and so on) is protected by column masking, not encryption. Users without permission to view it receive only masked values through every path (screens, the API, and sync), and only masked values reach the database on their devices. On cloud screens, My Number and bank account numbers stay masked by default even for users with permission, and are shown only after the user confirms their identity with a passkey.

Tenant Isolation

The cloud DB is separated into a Central DB / WS DB:

• Central DB: Shared information such as users, spaces (slim), and billing
• WS DB: The business data of each space (employees, attendance, payroll, accounting, etc.)

A WS DB cannot access another space's WS DB. We physically cut off data-leak paths.

In addition, Postgres RLS (Row Level Security) is applied to every table, providing a second layer so that even an application-layer bug cannot cause cross-tenant access. We further combine this with column-level masking based on permissions, so that when a role or permission changes, the rows and fields visible at the next sync are automatically narrowed. The handful of internal processes that must temporarily bypass RLS (limited to system paths such as initial provisioning) also declare where and why in a single place, with automated checks that enforce full coverage.

Access Control

Roles within a space:

Role	Permissions
OWNER	Full control of the space, billing, deletion
ADMIN	Member management, settings changes
MEMBER	General work
Custom roles per feature	Definable on the plugin side

Transferring OWNER is always done through an explicit action.

For integrations and automation, you can also use a Personal Access Token (PAT) tied to your own account. PATs always have an expiration date (no token can be issued without one), can be revoked in bulk together with logging out of all devices, and cannot be used for bulk-sensitive operations such as backups or exports. See Account for how to issue and manage them.

Audit Logs

Every write operation is recorded in the audit log:

• Who (user_id, device)
• When (timestamp)
• Where (space, menu)
• What (table, record ID, before/after)
• From where (IP, User-Agent)

The set of recorded action types is managed through types derived exhaustively from the implementation, so gaps in logging can't happen structurally. Writes also go through a single, unified code path, so sensitive actions are reliably captured.

Audit logs are stored as WORM (Write Once Read Many) and cannot be altered after the fact.

Authentication

• Password + two-factor authentication (TOTP)
• Passkeys (recommended)
• Google login
• Session list + per-session log out
• Device ID + suspicious-login detection

We do not use PPAP (sending ZIP passwords separately).

Network Protection

Traffic to the cloud passes through an edge WAF (Web Application Firewall), which blocks common attacks such as SQL injection and cross-site scripting by default.

Incident Response

If you discover a security issue, please contact us at security@niyase.com.