Security

Last updated: August 4, 2026

Nyvel is operated by MB „Mobilus sprendimas", a small partnership registered in Lithuania, company code 304959201, VAT LT100012029511, registered at Pastogės g. 8, LT-45475 Kaunas, Lithuania. Security contact: security@nyvel.io.

This page describes how the Service is built and operated, what assurances we can and cannot offer today, and where our commitments end. Read it alongside the Privacy Policy, the Terms, and the Coverage page, which states clause by clause what Nyvel evidences for each framework — and what it deliberately does not.

1. The shape of the system

Nyvel reads device security posture from the MDMs you already operate and turns it into a dated, framework-mapped evidence record. Three properties follow from the design rather than from policy, which is why they come first.

• Read-only. The MDM connectors have no write path. They call list and read endpoints only. No code in Nyvel can change a device setting, push a profile, issue a command, or modify anything in your MDM. Revoke the API credential and collection stops; nothing else changes.
• Agentless. We install nothing on your Macs — no agent, daemon, background process, kernel or system extension.
• Observation, not enforcement. We report what your MDM and devices report. Nyvel does not remediate, and it is not a control — it is evidence that a control is or is not in effect. Where a device is offline, an MDM API changes, or a collection script has not run, we report unknown rather than guessing.

The one thing that runs on your devices does not come from us. Some macOS settings are exposed by no MDM API — Gatekeeper state, screen-lock configuration, patch currency and a number of CIS hardening checks. To read those you deploy a short shell script through your own MDM, as a custom command or job. We never install it; it runs only when your MDM runs it; it only reads; and you read every line before deploying it, because the full source is shown to you in the app. It carries its own version stamp and collection timestamp, so a stale or silently failing script is visible as stale rather than mistaken for current — signals older than seven days are dropped and their checks report unknown. Decline the script and the Service still works, with narrower coverage.

2. Where your data lives

The primary database, application workloads and backups are in the European Union. The database and the API run in Frankfurt, Germany, and encrypted off-provider backups are held in object storage pinned to the EU jurisdiction. One category leaves the EU: alert and invitation email is sent through a US provider, and alert content can include device names — so if you subscribe to alerts, that content may be processed and stored in the United States.

Storage is not the whole picture, so to be precise about the rest: both providers are US-established companies, and our web layer runs on a global network, so pages are served from wherever you are. Data at rest stays in the EU; serving and support access are not confined to it. Where a provider processes personal data outside the EEA we rely on the European Commission's Standard Contractual Clauses as incorporated in that provider's data-processing terms, with the UK International Data Transfer Addendum where UK law applies. The Privacy Policy lists the providers.

To be specific about the API host, because "we run in Frankfurt" is usually where this stops: our application holds no persistent volumes — all state lives in the database and in backups — so there is no machine-local data to be copied out of the region. Our host does not segment its own subprocessors' access by region, so those subprocessors may access data from outside the EEA in the course of operating the platform. That access is covered both by the Standard Contractual Clauses in our executed agreement with them and by their EU-U.S. Data Privacy Framework certification.

3. What we hold, and what we refuse to hold

We read what your MDM exposes for the devices you place in scope: serial number, device name, model, OS version, tags and group membership, enrollment and supervision state, and the state of security settings. We do not collect file contents, messages, browsing history, keystrokes, screenshots, or device geolocation. Where a device shows a location, that is the site or group label your MDM reports — not the device's whereabouts.

Device names routinely contain a person's name, so we treat them as personal data. The Service is not designed for special categories of personal data under Article 9 GDPR, and our terms ask you not to place them in MDM device-name or location fields.

4. Credentials and keys

MDM API credentials are encrypted at rest with AES-256-GCM. The key is held as a hosting-provider secret and injected into the running process at boot — it is never stored in the database and never in our source repository. The consequence worth checking: a copy of our database, including a stolen backup, contains your MDM credentials only as ciphertext whose key is not in it.

Credentials are decrypted only to make a read call to your MDM. They are never written to logs, never returned by any API response, and never displayed back to you.

The encryption key can be rotated without any action by you. A superseded key stays accepted for decryption while a rotation is in flight, so credentials remain readable, and every stored credential is then re-encrypted under the new key. To be exact about the maturity of this: the capability was built recently and has not yet been exercised on production.

We recommend issuing Nyvel a dedicated, least-privilege, read-only API credential rather than reusing an administrative one.

5. Access control

• Authentication is delegated to WorkOS AuthKit. You sign in with Google or GitHub; we never see or store a password.
• Multi-factor authentication on your side. Sign-in is a Google or GitHub account, so the second factor is the one on that account — there is no Nyvel password for us to add a factor to, and the enforcement setting lives in your Google Workspace or GitHub organization, where your other applications already read it. The limit, stated rather than left implied: we do not enforce MFA on your members and cannot verify that your identity provider requires it.
• Multi-factor authentication on ours. Every administrative console that can reach production or customer data — hosting, database, object storage, CDN, authentication, payments, source control and email delivery — requires multi-factor authentication to sign in. This is the half of the MFA question a security review is usually really asking about, so it is stated here rather than left to be assumed.
• Roles. Every membership carries a role — owner, admin, viewer — enforced server-side, not in the UI. Billing, seat-count changes and renaming the organization are owner-only; connecting or editing an MDM connection, triggering a sync, seat assignment and team management require owner or admin; a viewer can read evidence and nothing else.
• Tenant isolation. Every read and write is scoped to the caller's organization in the query itself. A request for another organization's device, connection or export returns 404, not 403 — we do not confirm that another tenant's records exist.
• Audit log. Every organization has an append-only audit log — who signed in, added, changed or removed an MDM connection, generated an evidence export, changed settings or the framework selection, tracked or untracked a device, or changed a member's role. Owners and admins read it under Settings → Audit log. The application only ever appends to it: there is no edit or delete path.

6. Availability, backup and recovery

Small honest numbers rather than large unkeepable ones.

• Point-in-time recovery. Managed Postgres with a 30-day instant-restore window, so any state within that window is recoverable to the second.
• Independent off-provider backup. A nightly encrypted dump is written to object storage at a different provider, in the EU. It is encrypted with a public key, so the machine that writes backups cannot read them — the private key does not exist in that environment. Each upload is verified by reading the object back and comparing SHA-256, because an upload's exit code is a claim rather than proof. Backups are kept 90 days, and the job runs under a database role with read access and no write access, so a compromise of it cannot alter production.
• Recovery point: at most 24 hours off-provider, and seconds via point-in-time recovery.
• Restore, tested rather than assumed. On 3 August 2026 we restored the latest off-provider backup into an empty database in 39 seconds, and asserted the restored contents — device count, signal count, schema version — rather than trusting that the command exited cleanly. We re-test monthly, and the test fails if the newest backup is more than 36 hours old, so it also proves the job is still running.
• Service level. We do not offer a contractual uptime SLA. We target a support response within 2 business days.
• Status and history: live status page. History accrues from the day it went live; we cannot retroactively evidence what we did not measure.
• Continuity of evidence. A gap in our availability is not a gap in your evidence: collection is polled and resumes, and every poll writes a hash-stamped observation row — so the record shows when each device was actually observed instead of implying continuous coverage.

7. Subprocessors and data processing

The providers we rely on, what each processes, and where, are listed in section 4 of the Privacy Policy. Each is covered by a data-processing agreement, and we give 30 days' notice of a new subprocessor we appoint directly, and prompt pass-through notice when an existing provider changes its own sub-processors — before effectiveness where the upstream notice period permits — each with a right to object.

The MDM platforms you connect are your systems, not our subprocessors — you instruct us to read from them. If you configure a Slack or Telegram endpoint for compliance alerts, those alerts contain device names, and sending them is a disclosure to a provider you chose.

If you need a Data Processing Agreement under Article 28 GDPR — most organizations do before connecting an MDM — request one at support@nyvel.io.

8. Incident response and breach notification

If we learn of a personal-data breach affecting your data we notify you without undue delay — what we know, what we are doing, and what we recommend you do.

We deliberately do not promise a tighter hour count than our own upstream providers give us: theirs range from 48 to 72 hours, and a promise faster than the slowest link in the chain would not be one we could keep.

9. Deletion

Fleet and evidence history is retained while your organization's account is active — retaining history is the point of a compliance-evidence service.

• Disconnecting an MDM stops collection from it immediately.
• On account deletion or a written request, we delete your organization's records from the live database within 30 days.
• Deletion is not instantaneous everywhere, and we would rather set out the tail than imply it does not exist: recoverable database history purges within 30 days, encrypted off-provider backups within 90 days, and operational logs at our hosting provider within 90 days.
• So: complete erasure within 90 days, except where law requires longer retention, such as invoicing and tax records.
• You can export your evidence before deleting, and we will help you do it.

10. What we do not have yet

An honest list, because the alternative is that you find out later.

• No SOC 2 report and no ISO 27001 certificate. Not scheduled yet. If an audited report is a hard requirement for you, tell us at support@nyvel.io — knowing which report you need, and by when, is what moves it up the list.
• No independent penetration test yet. Of everything missing from this page it is the one we consider most worth adding, and we will publish the summary when it exists rather than a promise beforehand.
• No MFA that we enforce, or can evidence, for your members. Sign-in is delegated to Google and GitHub, so the requirement lives in your identity provider and we cannot attest that it is switched on. We are not going to describe this as coming soon: with no password of our own, an additional factor imposed by us would sit on top of one your provider already applies. If your policy needs Nyvel itself to enforce or evidence it, tell us at support@nyvel.io — knowing that a real buyer needs it is what would move it.
• No contractual uptime SLA, and no uptime history before our status page went live.
• We are new. No amount of page copy substitutes for a track record and we will not pretend otherwise. What we offer instead is a read-only pilot on a subset of Macs you choose, in which every result Nyvel shows can be checked against the source field in your own MDM.

11. Reporting a vulnerability

Email security@nyvel.io with what you found, how to reproduce it, and how you would like to be credited. We acknowledge within 2 business days and keep you updated until it is closed. We will not pursue legal action for good-faith research that stays within your own organization's data, avoids degrading the Service, and does not access other customers' data.