Changelog

We’ve added NIS2 as a first-class framework snapshot in the Compliance Center so you can quickly understand how your device and asset posture maps to NIS2 Article 21 requirements.

What’s new

• NIS2 framework card in Compliance Center

  • New NIS2 card appears in the Framework Snapshot row alongside other frameworks.

  • Shows:

    • Overall NIS2 compliance score (0–100%).

    • Status badge using the same thresholds as other frameworks:

      • On track: 80–100%

      • Need attention: 50–79%

      • At risk: 1–49%

      • Not started: 0%

    • Issue indicators by severity (Critical, High, No Issues), reusing existing icons and colors.

  • Fully compatible with the new horizontal scroll/overflow behavior for framework cards.

• NIS2 details panel

  • Clicking the NIS2 card opens a details panel with:

    • Overall NIS2 score and status badge.

    • At least 3–4 key NIS2 categories with their individual scores, such as:

      • Access Control & Asset Management (Art. 21(2)(i), (j))

      • Cryptography / Encryption (Art. 21(2)(h))

      • Vulnerability Handling & Secure Maintenance (Art. 21(2)(e))

      • Basic Cyber Hygiene / Endpoint Protection (Art. 21(2)(g))

      • Data Handling & Media Controls (device-level)

      • Asset Lifecycle Controls (Decommission / Disposal)

    • An Issues section listing top device/asset-related NIS2 gaps, for example:

      • Devices missing critical security controls (e.g., unsupported OS, missing EDR).

      • Devices without full inventory/ownership data.

      • Devices lacking encryption or screen lock.

• No-issue state for NIS2

  • When there are no NIS2 gaps, the NIS2 details panel shows a “No issues found for NIS2” view, using the same empty-state styling as other frameworks and reinforcing continuous monitoring.

• Handling of manual controls

  • NIS2 categories that are MANUAL-only (for example, Asset Lifecycle Controls (Decommission / Disposal) with control OFF-1) are:

    • Shown as “Not Supported” instead of “At Risk”.

    • Excluded from NIS2 score calculations, so they do not drag your score down for controls that cannot be automatically validated.

• Controls with no matching devices

  • Non-manual controls that are in scope but have 0 matching devices (e.g., Linux-only control when the org has only macOS/Windows) still appear, but:

    • All related stats show 0 (0 devices / 0 compliant).

    • They do not break the UI and are not treated as compliant by default.

• NIS2 placeholder card when not enabled

  • If NIS2 is not enabled in your Compliance Scope:

    • The active NIS2 snapshot card is hidden.

    • A placeholder NIS2 card appears after all active frameworks with a clear CTA to enable NIS2 in settings.

  • This follows the same layout and behavior as other framework placeholders.

How to enable

1. Go to Compliance settings → Framework Scope.

2. Select NIS2.

3. Open Compliance Center → Framework Snapshot to see the NIS2 card and details.

We’ve launched a new first-time experience (FTUX) to help new admins get Swif.ai configured faster and with less guesswork.

What’s new

• Onboarding Questionnaire (Steps 1–3)
  After signup, new admins are guided through a short questionnaire:

  • Company details – Capture basic org info, including number of employees.

    • If you enter more than 50 employees, you’ll see a new optional setup item to “Set up company sign‑in (SSO)” in the Setup Guide.

  • Compliance – Select the compliance frameworks you care about (SOC 2, ISO 27001, HIPAA, NIST, NIS2, etc.), or choose to request a template.

    • Any supported frameworks you pick are automatically set as your Active Compliance Scope in the Compliance Center.

    • If you choose “Request a Compliance Template” or “Not right now”, we’ll surface a follow‑up step in the Setup Guide so you can finish configuring your scope later.

  • Devices – Tell us which device types you manage (macOS, Windows, Linux, iOS & iPadOS Devices, Android Devices).

    • These selections are used as defaults anywhere you create Smart Device Groups or turn on Recommended Policies, so you don’t have to re‑select OS types every time.

• Onboarding completion screen
  Once you’ve finished the questionnaire, you’ll see a new Onboarding Complete page and will be taken directly into the Setup Guide on your next login instead of the old FTUX view.

• New Setup Guide page (your default landing page after onboarding)
  The Setup Guide is now its own page and becomes the default landing page for new admins after onboarding.

  • Recommended steps

    • Prepare Smart Groups – Create Smart Device Groups with your questionnaire OS choices pre‑selected, including iOS & iPadOS and Android.

    • Turn on Recommended Policies – Enable recommended security policies with device types pre‑selected from your questionnaire answers.

    • When you complete all recommended steps, you’ll see a success banner with an option to “Remove this page as default”, which returns your login landing page to the standard app home.

  • Optional steps

    • Optional items (including Shadow IT Discovery, now moved from the old “Get started” block on the homepage) live in a dedicated Optional Steps section.

    • You can either complete an optional step or “Skip for now”—skipped steps still count toward the All Setup Steps Completed state so you can clear your setup checklist intentionally.

  • All steps completed state

    • Once all recommended and optional steps are either completed or skipped, the Setup Guide shows an “All Setup Steps Completed” banner, with the same option to remove it as your default landing page.

We’ve refreshed the Swif agent installer across all three desktop platforms to make device enrollment smoother, clearer, and more consistent.

macOS

• Simplified step flow

  • Removed the separate “Pre-check” tab and merged it into Basic Information to reduce the number of steps.

• Improved copy and guidance

  • Updated welcome screen and finish screen text to better explain what’s happening and what users should expect.

  • Shortened and clarified Permissions instructions so users can more quickly grant required access.

• Clearer MDM setup

  • Renamed the “Installation Instruction” step to “Install MDM profile” to better match what the user is doing.

  • Made the MDM instruction frame scrollable so larger images and content are easier to view.

  • Added an inline banner when an old MDM profile is detected, so users understand why there’s a conflict and what to do.

Linux

• Guided, Linux-specific flow

  • Updated Introduction copy to clearly explain what the Swif agent does.

  • Added a dedicated Password Permission step to request sudo credentials up front (required on Linux).

• Better device context and options

  • Updated Basic Information step to:

    • Include BYOD (Bring Your Own Device) selection.

    • Add a Read-Only enrollment option for devices that should not be fully managed.

• Install and enrollment clarity

  • Refreshed the Ready to Install step with clearer messaging on what will happen next.

  • Shows an inline banner if an old MDM is present, helping prevent confusing failures.

  • Updated the Device enrollment complete screen with clearer success messaging and next steps.

Windows

• Aligned flow with macOS/Linux

  • Standardized the installer steps: Introduction → Password Permission → Basic Information → Ready to Install → Device enrollment complete.

• Improved messaging

  • Refined copy in Introduction, Password Permission, and Basic Information to match the new cross-platform tone and to set expectations.

• Install step enhancements

  • Updated Ready to Install contents for better clarity on what’s being installed.

  • Added an inline banner on the install step when an existing MDM is detected to warn users about potential conflicts.

• BYOD support

  • Ensured the Device enrollment complete screen supports and reflects BYOD flows consistently.

Behavior & quality improvements

• The installer:

  • Enrolls macOS, Windows, and Linux devices using the new UI flows.

  • Prevents duplicate mounting of the installer volume (per the earlier Linux mounting issue).

You can now build much more flexible notification rules in the Swif.ai web app.

What’s new

• Multiple conditions per notification rule

  • Add several conditions to a single rule (e.g. “Device OS = macOS” AND “Country in US, CA”).

  • Group conditions and configure AND / OR logic within a group and between groups.

• Visual condition/group builder

  • Clear grouping for complex logic like:

    • (Condition A AND Condition B) OR (Condition C)

  • Drag to reorder conditions within a group.

  • Drag to reorder entire groups without breaking the logic connectors.

• Full create & edit support

  • Create new rules with multiple conditions directly from Settings → Notifications.

  • Edit existing rules and see all of their groups, operators, and values reconstructed from the backend.

  • Change any part of a rule (conditions, order, logic) and the structure is preserved on save.

• Backwards‑compatible with legacy rules

  • Existing single‑condition rules automatically load into the new builder.

  • You can keep them as‑is or expand them by adding more conditions/groups.

• Better validation & safety

  • Rules must have at least one valid condition before they can be saved.

  • Inline validation for:

    • Missing required fields (e.g. no value or operator selected).

    • Invalid operator/value combinations for a given field.

  • Clear error messages explain what needs to be fixed before continuing.

Why it matters

This change makes it much easier to express real‑world notification logic without piling up lots of separate rules.

You can now send notification rules via SMS in addition to existing channels.

What’s new

• Added SMS as a notification channel when creating or editing a notification rule.

• You can manually enter one or more phone numbers to receive SMS alerts (we don’t auto‑pull from team member profiles).

• Phone numbers are validated inline (format, required fields, no duplicates) with clear error messages.

• SMS appears alongside other channels (Email, Slack, etc.) in:

  • Rule creation/edit forms

  • Rule details / summary views

• Editing an existing rule with SMS correctly:

  • Preloads the saved phone list

  • Lets you add, remove, and modify numbers

  • Properly clears SMS config if you disable the SMS channel

How it works

• In Notifications → Create Notification Rule (or Edit):

  • Enable SMS in the notification channels section.

  • Add one or more phone numbers (E.164‑like format, e.g. +15551234567).

  • Save the rule; the configuration is sent to the backend as:

    • notificationType: "SMS"

    • phones: ["+15551234567", ...]

• SMS can be used together with any other channels without interfering with their configuration.

You can now create geofences that span multiple countries/regions in a single “By Area” configuration.

What’s new

• Multi‑country selection in “By Area”

  • Add multiple rows and choose a different country in each (e.g., Vietnam, United States, United Kingdom, Australia).

  • The header now shows a “Countries Selected” counter that reflects how many countries are actually selected (rows without a country don’t count).

• Clear visual highlighting on the map

  • Every selected country/region is highlighted on the map so it’s easy to see the full coverage of your geofence.

  • When you remove a country row, its highlight is also removed from the map.

• Country / State / City hierarchy

  • Each row supports:

    • Country (required for that row)

    • Optional State (e.g., United States → California)

    • Optional City (e.g., San Francisco)

  • The Countries Selected count is based on countries only:

    • 1 row with “United States of America” + “California” still counts as 1 country.

    • City selections do not change the country count.

• “Focus” (zoom) for quality‑of‑life

  • Each row has a Focus control that zooms the map to that row’s region (country/state/city), making it easier to verify specific locations.

• Safer validation behavior

  • You can’t save a By Area geofence if no row has a country selected—you’ll see an inline error on the Country field (e.g., “Country is required”).

  • Extra empty rows are allowed and do not affect the country count or block saving, as long as at least one country is selected.

Behavior details & examples

• Creating a simple geofence:

  • 1 row with Country = Vietnam → header shows “Countries Selected: 1 country” and the map highlights Vietnam.

• Multiple countries:

  • 4 rows with Vietnam, United States of America,
    United Kingdom of Great Britain and Northern Ireland, Australia →
    header shows “Countries Selected: 4 countries”, and all four regions are highlighted on the map.

• Editing and deleting:

  • When you reopen an existing geofence, all previously selected rows and regions are restored.

  • Deleting a row:

    • Removes it from the list.

    • Decrements the country count.

    • Removes that region’s highlight from the map.

This update supports more complex compliance and security scenarios (like managing access for sanctioned or sensitive regions) while keeping the UI predictable, map‑driven, and easy to audit at a glance.

You can now use RustDesk as a remote desktop provider for Windows devices in Swif.

What’s new

• Always-available Remote Desktop button

  • The Remote Desktop CTA on Windows devices is now always enabled.

  • Clicking it opens a provider dropdown instead of being disabled when not configured.

• Choose your provider (Windows)

  • For Windows devices, you can choose:

    • Splashtop (Deprecated Soon)

    • RustDesk

  • Each provider row shows:

    • Policy status: Configured or Not Configured

    • Action: Connect (when configured) or Configure (when not configured)

• Clear “Configured / Not Configured” states

  • Not Configured is shown when:

    • No remote desktop policy exists for that provider, or

    • A team policy exists but the device doesn’t have it applied, or

    • The policy exists but device-level enable flags are off.

  • Configured is shown when:

    • A valid policy is applied to the device and enableRustdesk / enableSplashtop is enabled.

  • Clicking Configure routes you to:

    • Create a new policy (if none exists),

    • Assign an existing policy to the device, or

    • Enable configuration if it’s currently disabled.

• Connection flow with ID & password (RustDesk + Splashtop)

  • When you click Connect on a configured provider, Swif:

    • Calls the backend to open a remote desktop session.

    • Shows a screen with the connection ID and password when available (no dynamic link yet).

  • If the connection can’t be established or data is missing:

    • You see a clear notice and a Retry button.

    • Clicking Retry triggers a new attempt and, if successful, shows the ID & password screen.

• Better handling of “taking a while” states

  • Instead of a small tooltip, the new layout explains that remote desktop might take time to be ready.

  • A Refresh CTA lets you check again when the session is likely available.

• Improved tooltip copy

  • The Remote Desktop tooltip now focuses on how to proceed, e.g.:

    • “Choose a Remote Desktop provider to connect to this device”

  • This replaces blocking or error-focused language.

• Controller downloads for admins

  • Team admins can download RustDesk/Splashtop controllers directly from Swif:

    • macOS

    • Windows

    • Linux

  • Each download button points to the correct OS-specific installer.

  • Visibility/behavior for non-admins follows the product’s role-based access design.

Availability

• Supported for Windows devices in Swif’s WebApp.

• RustDesk is now available alongside Splashtop, with Splashtop clearly marked as “Deprecated Soon” for Windows.

Learn more

Full setup and usage guide for Windows is available here:
Remote Desktop for Windows – Connect with RustDesk
Remote Desktop for Windows: Connect with RustDesk | Help Center | Swif.ai

We’ve added multi‑region support for Mobile Device Management (MDM) in the EU.

What’s new

• MDM services can now operate across multiple regions, including EU.

• Devices are routed to the correct backend region based on the team’s environment/domain (EU vs non‑EU).

• Requests and callbacks from devices are handled according to the team’s associated environment, ensuring EU data stays within the EU region when applicable.

How it works (high level)

• Teams are classified as EU or non‑EU based on their domain and environment (Entity Management System).

• Depending on the team’s environment, device communication is directed to:

  • https://app.swif.ai for non‑EU teams

  • https://app.eu.swif.ai for EU teams

• The backend retrieves and caches all teams, and then routes incoming device queries to the appropriate regional API.

Why this matters

• Enables region‑aware MDM operations for EU tenants.

• Helps support data residency and compliance requirements by keeping EU device traffic within EU infrastructure.

• Lays the groundwork for more scalable, region‑specific MDM capabilities.

For more details, you can visit Swif.ai EU Data Residency.