Skip to main content

How the FileWave Client Communicates

What

This article explains how the FileWave Client securely communicates with FileWave infrastructure components during enrollment and ongoing operations. It covers certificate-based authentication, transport mechanisms, and platform-specific communication flows so administrators understand what talks to what, how, and why.

A key design principle of FileWave communication is mutual TLS (mTLS), where both client and server authenticate each other using certificates issued by the FileWave Certificate Authority (CA).

When / Why

Understanding FileWave client communication is important when:

  • Designing network topology (firewalls, proxies, NAT, boosters, NATS)
  • Troubleshooting enrollment or check-in failures
  • Auditing security posture (certificate usage, authentication, encryption)
  • Explaining FileWave behavior to security or infrastructure teams

This knowledge is especially critical in modern deployments where communication is brokered through NATS rather than direct point-to-point HTTP(S) connections.

How

Enrollment

At this point, you have either installed the FileWave client onto a device manually, or the device has received the client automatically (for example via Automated Device Enrollment).

  1. The client uses the configured server address to initiate a connection to the FileWave server.
  2. The client downloads the FileWave CA certificate from the server.
  3. The client generates a unique Client ID.
  4. The client generates a Certificate Signing Request (CSR) and securely stores the private key locally.
  5. The client sends the Client ID, device name, and CSR to the server.
    1. The client polls the server on the tickle/heartbeat interval until a certificate is issued.
    2. The server signs the CSR and returns a client certificate.
    3. The client validates the returned certificate against:
      • Its locally stored private key
      • The FileWave CA certificate
  6. The client record is created in FileWave Central:
    1. Auto-add: The client is automatically approved and placed into the configured auto-add group.
    2. Upgraded client: The client is automatically approved and resumes normal operation.
    3. Manual vetting: The client remains pending in Client View → New Clients until approved.

FileWave uses mutual TLS (mTLS) from this point forward. All subsequent communication requires both the client and server to present valid certificates signed by the FileWave CA.

There is no longer a compatibility mode. Legacy documentation such as What is Compatibility Mode? applies only to historical versions and should not be used for modern deployments.

Daily Communication

The FileWave server continuously recalculates models and smart groups. As a result, a client check-in may result in new manifests even when the assigned model itself has not changed.

Modern FileWave deployments use NATS as the primary communication transport for tickle and command signaling.

macOS and Windows

Tickle (Check-in)

  1. The tickle interval expires (configurable via Superprefs).
  2. The client initiates communication via NATS.
  3. A mutual TLS handshake occurs:
    • The server validates the client certificate.
    • The client validates the server certificate.
  4. The server responds with the current model number.
    1. If the model number matches, no model manifest is downloaded.
    2. If the model number differs, the client downloads the updated manifest.
  5. The client processes the manifest(s).
  6. The client downloads required Filesets:
    1. From the server directly or via a Booster.
    2. The client validates the Booster certificate against the same FileWave CA.
    3. The Booster validates the client certificate and checks revocation status (CRL).
    4. If certificate validation fails at any stage, the TLS handshake fails and no data is transferred. The failure is reported back to the FileWave server.

Verify

  1. A verification check-in occurs (default: every 24 hours, configurable via Superprefs).
  2. After successful mTLS authentication:
    • The client verifies Fileset state
    • Inventory is refreshed
    • Files are healed according to Fileset verification settings

Verification also occurs when the client service starts (for example after a reboot) and can be triggered manually via Client Monitor, Client Info, or command line.

Android EMM

FileWave Android EMM communication is mediated through Google’s Android Management API (AMAPI).

At Model Update

  1. A single manifest is generated from all Android Policy Filesets assigned to the device.
  2. Application assignments and permissions are included.
  3. The manifest is sent to Google via AMAPI.
  4. The Android device retrieves updates from Google.

Ongoing Operation

  1. FileWave polls Google approximately every 5 minutes for device status updates.
  2. Smart group changes trigger regeneration of manifests and updates via AMAPI.

iOS / iPadOS

FileWave communicates with Apple devices using standard MDM push and check-in mechanisms.

At Model Update

  1. A push notification is sent to the device via Apple Push Notification service (APNs).
  2. The device initiates a connection to the FileWave MDM server.
  3. Updated manifest data is delivered to the device.

Ongoing Operation

  1. The inventory interval is reached (default: 24 hours).
  2. FileWave sends an APNs push requesting the device to check in.
  3. The device connects to the FileWave MDM server.
  4. Any updated manifests are delivered.

Related Content

Digging Deeper

FileWave’s use of mutual TLS ensures that:

  • Only trusted clients can communicate with the server
  • Clients are protected from impersonation or man-in-the-middle attacks
  • Boosters cannot serve unauthorized devices

The introduction of NATS improves scalability and resilience by decoupling client signaling from traditional request/response patterns. This allows FileWave to efficiently handle large device fleets while maintaining strong security guarantees.

From a security perspective, FileWave’s communication model aligns well with modern Zero Trust principles: authenticate everything, encrypt everything, and assume the network is hostile by default.

No comments to display

Back to top