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 pointpoint, you have either installed the FileWave client onto a computer,device manually, or the computerdevice has gottenreceived the client fromautomatically DEP.(for example via Automated Device Enrollment).

1. ClientThe client uses the configured server fieldaddress to makeinitiate a connection to the serverFileWave server.
2. ClientThe client downloads the FileWave CA infocertificate from serverthe server.
3. ClientThe client generates clienta IDunique Client ID.
4. ClientThe client generates CSRa (Certificate Signing Request),Request (CSR) and savessecurely 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
      • ClientThe sendsFileWave client ID, name, CSR to server
        1. Client polls server (on tickle/heartbeat interval) until certificate is ready
        2. Server sends the clientCA certificate
        3. Client
      verifies the certificate against the local key and the CA it downloaded
6. ClientThe client record is addedcreated (andin certificateFileWave is created)Central:
   1. (Auto-add)add: ClientThe client is automatically approved and goesplaced into the selectedconfigured automatic auto-add foldergroup.
   2. (upgradedUpgraded client)client: ClientThe client is automatically approved,approved and continuesresumes normal operationoperation.
   3. (Vetting)Manual Clientvetting: sitsThe client remains pending in the new client UI (Client viewView → New clientClients →until Desktop Clients) till approved approved.

IfFileWave 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 olderno thanlonger 13.1 it will not connect ifa compatibility mode. isLegacy disableddocumentation (see:such as What is Compatibility Mode?) applies only to historical versions and should not be used for modern deployments.

Daily Communication

The FileWave server iscontinuously updatingrecalculates models and smart groups. As a result, a client check-in may result in new manifests botheven when the assigned model updatesitself has not changed.

Modern FileWave deployments use NATS as the primary communication transport for tickle and whencommand calculating smart group updates (see inventory preferences for time variable), so when a check-in happens the model may not have changed, but there may be new manifests for the client nonetheless.signaling.

macOS and Windows 

Tickle

 (Check-in)

1. CheckinThe (AKA Tickle)tickle interval expires (Changeableconfigurable withvia Superprefs, see: Creating a Superprefs Fileset) has passedSuperprefs).
2. ClientThe reachesclient outinitiates tocommunication servervia NATS.
3. ServerA verifiesmutual certificateTLS handshake occurs:
   • The server validates the client certificate.
   • ServerThe client validates the server certificate.
4. The server responds with the current model numbernumber.
   1. If the model number on server matches client, thenmatches, no model manifest is downloaddownloaded.
   2. If the model number does not matchdiffers, the server, client downloads manifestthe fromupdated servermanifest.
5. ClientThe client processes the manifest(s).
6. ClientThe reaches out to either server or booster andclient downloads fileset(s)required Filesets:
   1. (ifFrom booster)the Clientserver reachesdirectly outor tovia boostera requesting fileset IDBooster.
   2. ClientThe verifiesclient validates the boostersBooster certificate is valid against the same CA (Certificate Authority - AKA your FileWave server) that the client uses. CA.
   3. The Booster checksvalidates the client certificate against the CA it downloaded from the server and thechecks CRLrevocation status (Certificate Revocation List - Certs that have been made invalid) CRL).
   4. If thecertificate certificatesvalidation (boosterfails orat client)any are not valid, not signed by the CA or part of the CRL,stage, the TLS handshake fails and the connection is dropped (with no data beingis transferred),transferred. theThe failure is reported back to the FileWave server.

Verify

1. AdditionalA verification check-in,in byoccurs default(default: every 24hrs.24 ('Filehours, Checkconfigurable Interval',via changeable with Superprefs, see: Creating a Superprefs Fileset)Superprefs).
2. After Server/Clientsuccessful certificatemTLS confirmation,authentication: the
   • The client confirmsverifies statusFileset ofstate
   all Filesets and
   • Inventory andis 'refreshed
   • Files are healed according to Fileset healsverification' anysettings
   files
   as configured within Filesets.

Verification also occurs when the client service commencesstarts (e.g.for example after a reboot) and can be triggered manually throughvia Client Monitor/InfoMonitor, Client Info, or command lineline.

on the device.

Android EMM

ReviewFileWave theAndroid topologyEMM oncommunication Defaultis TCPmediated andthrough UDPGoogle’s PortAndroid UsageManagement forAPI a visual on how things connect.(AMAPI).

At Model Update

1. A single manifest is createdgenerated from all Android Policy Filesets (AKA Policy Fragments) associatedassigned to the devicedevice.
2. AnyApplication Appassignments associatedand 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 (includingAPNs).
app
2. The permissions)device areinitiates addeda connection to the manifestFileWave MDM server.
3. ManifestUpdated manifest data is sentdelivered to AMAPIthe (Android Management API)
4. EMM Android device reaches out to Googledevice.

RestOngoing of the timeOperation

1. The inventory interval is reached (default: 24 hours).
2. FileWave reachessends outan toAPNs Googlepush everyrequesting 5minthe device to check for new devices and verify activityin.
3. IfThe theredevice connects to the FileWave MDM server.
4. Any updated manifests are smart-groups update, a new manifest would be created and sent to AMAPI (see Android EMM Known Issues KB)delivered.

iOS

Related

ReviewContent

the

topology
• Creating ona Superprefs Fileset
• Default TCP and UDP Port Usage for a visual on how things connect.

  At Model Update

  1. At model update a push notification is send to the device asking it to verify
  2. TheConfiguring iOSInventory devicePreferences
  connects
  3. Android EMM Known Issues

Digging Deeper

FileWave’s use of mutual TLS ensures that:

• Only trusted clients can communicate with the FileWave server
• The new changes in the manifestClients are sent
protected from

Restimpersonation ofor theman-in-the-middle time

1. Next inventory interval is hit

   Default is 24hrs. Configured in: Inventory preferences Meaning the last time we have talked to the device. So if you updated the model at 4pm on Friday, then 4pm Saturday would be the next interval

   attacks
2. Boosters

   FileWavecannot sendsserve outunauthorized a Push to Apple asking the device to talk to FileWave MDM server

   devices

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

From a security perspective, FileWave’s communication model aligns well with themodern FileWaveZero server

Trust principles:

authenticate

Theeverything, newencrypt changeseverything, inand assume the manifestnetwork areis senthostile by default.