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	SQLite encryption (OS keyring integration)
Mobile DB	SQLCipher (expo-sqlite v16+)
Cloud DB	Column-level encryption (PII) + at-rest encryption
Backup files	Same encryption applied
Communication	TLS 1.3

Sensitive information (My Number, bank account numbers, etc.) is also encrypted at the application layer when stored.

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.