The Skedda Companion is a lightweight tray app for Mac and Windows that automatically verifies your office presence and checks you into bookings - no browser tab, no manual interaction required.
Once installed and signed in, the app runs quietly in the background. When your laptop connects to the office network, Skedda marks you as seen on-site and, if your workplace has enabled it, automatically checks you into eligible bookings.
How It Works
1. Your admin sets up occupancy tracking - Your workplace configures Skedda to recognise when devices connect to the office network and optionally enables automatic check-in rules for bookings.
2. The app is installed once. Your IT team may install it for you, or you can download it yourself.
3. You sign in once. If your IT team set the app up for you, you may already be signed in. Otherwise, sign in with your Skedda account. You'll stay signed in across restarts.
4. Skedda handles the rest - When you arrive at the office and your laptop connects to the network, you're automatically marked as on-site and checked into eligible bookings.
Installing Skedda Companion
For information about how to automatically deploy Skedda Companion across IT-managed devices, read our detailed walkthrough here. If your IT team has already installed it for you, skip to Finding the Companion After Installation.
1. Download the installer for your operating system:
- Mac: Download
- Windows: Download
2. Run the installer.
Your device may prompt for your system password.
3. The app launches automatically after installation.
Finding the Companion After Installation
Skedda Companion does not appear in your Dock (Mac) or on your Taskbar (Windows). It lives in your system tray or menu bar.
Mac: Look in the menu bar at the top-right of your screen for the Skedda icon.
Windows: Look in the system tray at the bottom-right of your taskbar. You may need to click the "^" arrow to expand hidden tray icons.
Click the icon to see your status:
Status | What it means |
Seen on-site today at [venue] | You're all set and Skedda has seen you in the office today. |
Not yet detected on-site today | You're all set. You just haven't been seen on the office network today. |
Status: Checking... | The app has just started and is checking in with Skedda. It changes once the app has connected. |
Status: Setting up... | Your IT team's setup is in progress. There's nothing you need to do. |
Status: Waiting for setup | The app hasn't been set up for you yet. See the FAQs |
Status: Not signed in | You need to sign in. See below. |
Signing In
If your IT team set up the Companion for you, you don't need to sign in. Check the status in the tray menu. If it says you're seen on-site, or not yet detected on-site today, you're done.
1. Click the Skedda icon in your menu bar or system tray.
2. Click Sign In.
3. If you're already signed into Skedda in your browser, the sign-in completes quickly. If not, log in as normal. When you see "Authentication successful", allow your browser to open Skedda Companion if it asks, then close the tab.
4. You're done - sign-in persists across restarts, so this is a one-time step.
Day-to-Day Use
There's nothing you need to do after the initial setup. Here's what happens in the background:
1. You arrive at the office with your work laptop.
2. Your laptop connects to the office network.
3. Skedda Companion detects the connection and checks your IP against your venue's configured office network.
4. If there's a match, you're marked seen on-site in Skedda.
5. If you have a booking with an open check-in window and your workplace has enabled automatic check-in, Skedda checks you in automatically.
Note: You do not need to open Skedda or do anything manually. The app starts automatically when your laptop boots up.
Important to Know
The app must stay running for occupancy tracking and automatic check-in to work. If you sign out of or quit the app, it will no longer track your presence until you reopen and sign back in.
Automatic check-in is optional: it must be enabled by your Skedda administrator. If you're being marked on-site but not checked into bookings, check with your admin.
No precise location tracking: the app only checks whether your device is on a specified office network. It does not track your location beyond that.
FAQs
Do I need to open Skedda when I arrive at the office?
Do I need to open Skedda when I arrive at the office?
No. Skedda Companion verifies your presence automatically in the background when your laptop connects to the office network.
My IT team installed the app. Do I need to do anything?
My IT team installed the app. Do I need to do anything?
Usually not. Your IT team can sign the app in for you during installation. Click the Skedda icon and check the status. If it says Seen on-site today or Not yet detected on-site today, you're set up.
The app says "Waiting for setup". What do I do?
The app says "Waiting for setup". What do I do?
Your IT team's setup hasn't finished on this device. Let them know, or click Sign In... in the tray menu and sign in yourself. Either way works.
Does my administrator need to do anything?
Does my administrator need to do anything?
Yes - your admin needs to enable occupancy tracking and add the office's public IP address in Skedda settings. If you expect automatic check-ins, they also need to enable that in the relevant check-in rules.
I installed the app but wasn't automatically checked into my booking. What happened?
I installed the app but wasn't automatically checked into my booking. What happened?
Automatic check-in is an optional feature that must be enabled by your admin. Check with your IT team or Skedda administrator to confirm whether automatic check-in rules have been set up for your workplace.
Do I need to keep Skedda open in my browser?
Do I need to keep Skedda open in my browser?
No. Skedda Companion runs passively in the background and persists across restarts. There's no need to keep a browser tab open.
The app signed me out - what do I do?
The app signed me out - what do I do?
Open the app from your menu bar (Mac) or system tray (Windows) and sign in again. Once signed in, it will resume tracking automatically. If your IT team set up the app for you, avoid signing out. Signing out removes that setup, and you'll then need to sign in yourself or ask IT to set it up again.
Can I use this on a personal device?
Can I use this on a personal device?
Skedda Companion is designed for company-managed work laptops. Using it on a personal device is possible but not recommended. Check with your IT team or admin.
Is my data secure?
Is my data secure?
Yes. You're only marked on-site when your device is on your office network, which Skedda checks against your organisation's public IP addresses. Separately, so your admin can see the app is working, Skedda records when the app last checked in and which version it's running, from any network. This doesn't include your location. Skedda protects all data with encryption in transit, encryption at rest, and standard access controls. Occupancy data is not shared with third parties. By default, it is retained for 1 month and then deleted - your admin can adjust this period in Skedda's Data Retention settings.
I'm an IT admin and need to understand the security posture for this application. Where is this information?
I'm an IT admin and need to understand the security posture for this application. Where is this information?
Below you can find a comprehensive security-related overview of the Skedda Companion.
1. Functionality Overview
1.1 What Skedda Companion does
The Skedda Companion is a lightweight, native system-tray application that helps improve on-site detection accuracy for Skedda customers.
The app is installed on the user's device. The user signs in, or the organisation's MDM signs the app in at install time (zero-touch enrollment). While it runs, the app periodically pings the Skedda backend from the user's current network. The backend looks at the public IP the request comes from and compares it to the venue's configured on-site network ranges. If the IP matches, it marks the user as "seen-on-site" for that day. If the venue has auto-check-in enabled, this implies the user is automatically checked into their bookings for that day.
The app has no main window; its entire UI is a system-tray icon and menu.
1.2 End-to-end flow
Sign-in.
Option A: zero-touch enrollment (managed installs).
The MDM runs the app with an `install` command carrying the venue's enrollment key and the user's email. These values are held in memory only and never written to disk.
The app sends the key, the email and a device identifier to Skedda's enrollment endpoint over HTTPS.
Skedda checks that the key is valid and that the email belongs to an active member of that venue, then returns a device token.
Option B: manual sign-in.
The user clicks "Sign In..." in the tray menu, and the default browser opens Skedda's Companion sign-in page.
Skedda redirects to
skedda-companion://auth?token=….
The app validates the deep link strictly, then exchanges the token in the background for a device token.
Token persistence. The device token is stored in the OS keychain (see §2.1)
Pings. The app pings the Skedda backend over HTTPS on a schedule - each response tells the app when to ping next, depending on the venue's opening hours and the user's upcoming bookings. OS network-change events also trigger an immediate ping, in addition to the scheduled ones.
Server-side decision. Skedda identifies the user from the token, compares the request's source IP to the venue's on-site-network configuration, and — if the IP matches — marks the user "seen-on-site". If the venue has auto-check-in enabled, this implies their bookings for that day are then auto-checked-in.
Deauthorization. If the user no longer has an active membership at any Skedda venue, or the device is revoked, the backend tells the app to stop. The app deletes its token, stops pinging and shows "Waiting for setup".
App updates. 30 s after launch and every 24 h thereafter, the app checks for signed updates and applies them silently.
1.3 Architecture at a glance
Skedda Companion is a tray-only native Rust app built on Tauri v2. It has no webview - no HTML, no JavaScript, no remote content is ever loaded or rendered inside the app. This removes the entire "insecure webview" threat class (no CSP bypass, no XSS, no devtools exposure). The only code that runs inside the app is code Skedda built and signed: the application core plus the Tauri plugins it bundles. The app doesn't download or run code at runtime, apart from signed updates, which are verified before they're installed (§4.3)..
Ships as: macOS universal .app/.pkg (Apple silicon and Intel) and Windows NSIS (per-user install, no admin rights required)
2. Data the App Handles
2.1 Token scope — not a general-purpose Skedda token
The token stored by Skedda Companion is not a general Skedda login or web-session token. It is a device token: an encrypted token that identifies one user on one device, issued only for Skedda's on-site-detection flow (§1.2). Because it's tied to a single device, it can be deauthorized without affecting the user's other devices or the rest of the fleet.
The token does not grant the ability to sign into the Skedda app, read or change bookings directly, view other users' data, or call any other Skedda API.
2.2 Inventory
Item | What it is | How it moves | Where it lives on the device |
Device token | Encrypted bearer token identifying the user and device for on-site detection (§2.1) | Received from Skedda at enrollment or sign-in, then sent in each ping over HTTPS | OS keychain ( |
Local log entries | Timestamps, masked tokens ( | Never transmitted anywhere | OS log directory; rotated at 5 MB, 3 files retained |
Network-change signals | OS notifications that the device's IP or interface changed | Not transmitted — used only as a trigger to send a timely ping | Not stored |
Device identifier | Derived from the operating system's machine ID (Windows `MachineGuid`, macOS `IOPlatformUUID`). Used only to tell the user's devices apart. | Sent to Skedda at enrollment and when an older sign-in is upgraded. Skedda stores it with the device token. | Not stored by the app. Read from the operating system only when needed |
Enrollment key and email (managed installs only) | Values supplied by the MDM in the `install` command | Sent once to Skedda's enrollment endpoint over HTTPS | Process memory only. Never written to disk. |
2.3 What is NOT collected
Skedda Companion has no code path to collect: hostname, device name, MAC address, Wi-Fi SSID/BSSID or nearby networks, file contents, installed apps, browser history, keystrokes, screen/clipboard contents, microphone/camera/GPS, or any third-party analytics/telemetry/crash-reporting SDK. The only device-level value it uses is the machine identifier described in §2.2.
2.4 Retention on your device
Data | Retention |
Token in OS keychain | Until sign-out, deauthorization, uninstall, or manual removal |
Token, enrollment key and email in process memory | Until the app quits |
Log files | Rolling — max 5 MB/file, 3 files, oldest auto-deleted |
Ping payloads & network-change events | Not retained |
Server-side processing (retention, purpose, sub-processors, deletion rights) is governed by the Skedda Privacy Policy and DPA, not by this document.
3. What Skedda Companion Can Access on Your Device
3.1 Summary
Resource | Scope the app uses |
Keychain / credential store | Service |
Deep-link URL scheme | One scheme only: |
Filesystem | Its own log directory and the OS-managed updater staging directory. No other paths. |
Network | Outbound HTTPS only, to subdomains of your Skedda authority (e.g. *.skedda.com): app.<authority> for enrollment, sign-in and pings, and cdn.<authority> for signed update artifacts. |
Network-change notifications | Read-only OS events used as a ping trigger. No packets sent. |
System notifications | Posts its own notifications with hardcoded text. |
Launch at login | Per-user autostart entry (removable from the OS UI). |
Shell / other processes | Opens the user's default browser to one app-constructed Skedda URL during sign-in. No other process execution. |
Webview / embedded HTML | None. |
Camera / microphone / location / contacts | None. No plugin or crate for any of these is included. |
Machine identifier | Read-only, to derive the device identifier (§2.2) |
3.2 Controls an IT admin can enforce
The scopes above are what the app asks for. An admin can independently enforce that boundary at the OS or network layer, so that any future version, supply-chain incident, or runtime compromise would still fail if the app strayed outside this behaviour.
Network egress (most impactful). Allowlist outbound HTTPS from Skedda Companion to *.<your-Skedda-authority>:443 only (e.g. *.skedda.com:443, which covers both the app. host used for enrollment, sign-in and pings, and the cdn. host used for signed update artifacts); deny everything else. Effective via corporate egress proxy, Windows Defender Firewall per-app rule (deployable via Group Policy/Intune), or macOS MDM (Jamf/Kandji/Intune) application-layer firewall or Little Snitch. This single control caps every remote-reachable threat - the app has no other endpoints.
Filesystem. macOS PPPC profile denying Skedda Companion access to Documents, Desktop, Downloads, iCloudDrive, NetworkVolumes, Camera, Microphone, Accessibility, Full-Disk. Windows Controlled Folder Access with Skedda Companion not on the allow-list.
Code integrity. Windows WDAC or AppLocker allowlisting only the Skedda-signed Authenticode publisher. macOS Gatekeeper + Notarization enforcement via MDM, optionally Santa in lockdown with a binary rule
Autostart. Autostart. macOS MDM Managed-Login-Items, Windows Group Policy on HKCU…Run.
Enrollment key handling. Deliver the enrollment key only through your MDM. Command-line arguments, including the key, can be visible in the device's process list while the install command runs. On its own, the key can't sign anyone in. It can only enroll devices for existing active members of your venue.
4. Integrity & Trust
4.1 Network transport
All outbound traffic is HTTPS via reqwest with the OS trust store (SChannel on Windows, Secure Transport on macOS). https:// is hardcoded; there is no plaintext HTTP in production. Connect timeout 10 s, request timeout 30 s. No URL or header is sourced from untrusted input at runtime. The only externally supplied values are the enrollment key and email from your MDM.
4.2 Deep-link validation
The skedda-companion:// handler parses the URL with a standard library, then requires scheme skedda-companion, host auth, a single non-empty token query parameter of at most 4 096 bytes; duplicate or extra token keys are rejected. A tauri-plugin-single-instance guard ensures a second-launch forwards its deep link into the running process (no race).
The install command accepts exactly two flags, --enrollment-key and --user-email. Any other flags are ignored. The single-instance guard also forwards an install command from a second launch into the running process.
4.3 Signed updates
Skedda Companion updates are delivered via the Tauri updater plugin.. The update manifest is fetched from app.<your-authority> and the signed artifact is downloaded from cdn.<your-authority>. Every downloaded artifact is verified against a minisign public key embedded in the app binary before install; unsigned or mismatched payloads are rejected. Checks occur 30 s after launch and every 24 h; Windows installs run in passive NSIS mode without UAC (per-user scope).
4.4 Code signing & distribution
macOS: universal .app and .pkg (Apple silicon and Intel). The app uses AccessoryActivationPolicy to stay out of the Dock and Cmd-Tab. Signing and notarization are enforced in release CI.
Windows: NSIS per-user installer (installMode: currentUser, no admin elevation). Authenticode signed in release CI.
4.5 Secret storage
The token is held in the OS keychain via the keyring crate (macOS Keychain, Windows Credential Manager), under service com.skedda.companion. Writes are verified by reading them back, and a memory cache covers transient keychain failures. Sign-out and deauthorization clear the token from both memory and the keychain. Enrollment values supplied by your MDM are never persisted.
4.6 Logging
Structured logs via tauri-plugin-log to the OS log directory (stdout only in debug builds). 5 MB rotation, 3 files retained. Tokens are always masked to ***<last-3-chars>; request and response bodies are never logged verbatim.
4.7 Supply chain
Production dependencies are a small, audited set: Tauri v2 (core + updater/deep-link/autostart/notification/single-instance/log plugins), machine-uid (device identifier), reqwest (HTTPS), keyring (OS credential store), tokio (minimal feature set), serde, url. No third-party JavaScript ships in the binary (the only Node dependency is @tauri-apps/cli for build scripts). The repo runs routine dependency audits to surface advisories in these crates.
5. References
Skedda Data Processing Agreement: Please contact your Skedda Account Representative.
We use Microsoft Intune or another MDM. How do we deploy the app?
We use Microsoft Intune or another MDM. How do we deploy the app?
See Deploying the Skedda Companion. It covers silent install commands, detection rules, and zero-touch enrollment so employees don't have to sign in.