# Connectors
Source: https://docs.getprimo.com/ai/connectors
Connect external tools to Primo AI by registering Model Context Protocol (MCP) servers.
Connectors give [Primo AI](/ai/primo-ai) access to tools outside the platform. A connector is a Model Context Protocol (MCP) server that you register by URL. Once connected, the assistant can call that server's tools during a conversation — for example, to look up a page in Notion or act in another system.
## When to use a connector
Add a connector when you want the assistant to reach beyond Primo's own data:
* **Query another system** — pull information from a tool your team already uses.
* **Act in another system** — let the assistant perform tasks in a connected service.
* **Extend the assistant** — bring in any tool that speaks the Model Context Protocol.
If you only need the assistant to work with Primo data or your company's own instructions, you don't need a connector — use [knowledge base items](/ai/knowledge-base-items) instead.
## Prerequisites
* The **AI agent write** permission to add, re-authenticate, or delete connectors.
* The URL of an MCP server that supports OAuth authentication.
## Add a connector
Open **Settings**, select the **AI** section, then the **Connectors** tab.
The connector dialog opens.
* **Name** — a label for the connector, for example `Notion`.
* **Server URL** — the MCP endpoint, for example `https://example.com/mcp`.
Expand **Advanced settings** only if your MCP server does not support Dynamic Client Registration. Register Primo in the provider's OAuth console, then enter the **Client ID** and **Client secret**. Leave the secret empty for public clients that use PKCE.
Primo redirects you to authenticate with the MCP server. After you authorize access, the connector returns to Primo and its status becomes **Connected**.
## Connector statuses
| Status | Meaning |
| -------------------------- | ------------------------------------------------ |
| **Pending authentication** | Created, but authentication is not yet complete. |
| **Connected** | Authenticated and available to the assistant. |
| **Error** | The connection failed. Re-authenticate to retry. |
## Manage connectors
From the Connectors tab you can:
* **Re-authenticate** — refresh access when a connector expires or errors.
* **Delete** — remove a connector and its stored credentials.
## How Primo AI uses connectors
When a conversation needs an external tool, the assistant selects the relevant one from your connected connectors and asks you to approve the action before it runs. Open Primo AI and use the **Connectors** control in the message box to choose which connectors are active for a conversation. See [Primo AI](/ai/primo-ai).
# Knowledge base items
Source: https://docs.getprimo.com/ai/knowledge-base-items
Teach Primo AI your company's knowledge, policies, and reusable tasks by creating and publishing knowledge base items.
Knowledge base items are the instructions and reference material [Primo AI](/ai/primo-ai) draws on when it answers a request. Think of each item as something you would train a new team member on: a policy to follow, a procedure to run, or a fact to remember.
In the dashboard, knowledge base items appear as **skills** under the Knowledge base tab. Each item can capture reference knowledge (what is true) or behavioral guidance (how to act) — or both.
## When to use a knowledge base item
Create an item whenever the assistant should behave consistently with the way your company works, not just its general knowledge. For example:
* **Encode a policy** — "Devices must run the latest major OS within 30 days of release."
* **Standardize a procedure** — the exact steps your team follows to offboard a departing employee.
* **Record company facts** — approval thresholds, naming conventions, or who owns which tool.
* **Reuse a task** — a routine the assistant should be able to run the same way every time.
If it tells the assistant **how to act**, write it as a procedure. If it tells the assistant **what is true**, write it as reference. A single item can do both.
## Open the knowledge base
Open **Settings**, then select the **AI** section.
The tab groups items by status: **Published**, **Pending changes**, and **Unpublished**.
## Create an item
A new item opens in the editor.
Give it a short, specific name (up to 120 characters). The assistant uses the name to decide when the item is relevant.
State **when** the assistant should use this item, in one line (up to 1024 characters). The assistant reads the description to decide whether an item applies to a request, so describe the trigger, not the content — for example, "Use when an employee reports a lost or stolen device."
Write the knowledge itself in Markdown. Describe the policy, procedure, or facts in plain language, the same way you would brief a colleague.
Changes save automatically. The editor shows **All changes saved** once your work is stored.
## Publish an item
An item only reaches the assistant after you publish it. Drafts stay private.
* Click **Publish** to make a new item available to Primo AI.
* Edit a published item and its status becomes **Pending changes**. Click **Publish changes** to push the update.
* Click **Unpublish** to remove an item from the assistant while keeping the draft.
## Item statuses
| Status | Meaning |
| ------------------- | --------------------------------------------------------- |
| **Unpublished** | Draft only. Not visible to the assistant. |
| **Pending changes** | Published, but the draft has edits that are not live yet. |
| **Published** | Live and available to Primo AI. |
## How Primo AI uses your items
When you chat with the assistant, it scans your published items and pulls in the ones relevant to your request, then follows their guidance in its answer. The assistant only uses published items — it ignores drafts and unpublished items. Primo shares items across your company, so every teammate's assistant benefits from what you publish.
## Best practices
Keep each item focused on a single policy or procedure. Small, specific items are easier for the assistant to match and apply.
The assistant relies on the name and description to decide when an item applies. Make them specific.
Write as if briefing a new colleague. Avoid internal jargon the assistant can't interpret.
Publish early, watch how the assistant uses the item, and edit as needed. Republish to push changes.
## Feature-managed items
A Primo feature creates and maintains some items, such as an equipment or purchasing policy. These show a **Used by** label, and you can't edit or delete them from the knowledge base — manage them from the feature that owns them.
# Primo AI
Source: https://docs.getprimo.com/ai/primo-ai
Chat with Primo AI, a context-aware assistant that helps you search, understand, and act across the platform.
Primo AI is an in-app assistant that answers questions and performs actions across your workspace. It understands the page you are on, reads your published [knowledge base items](/ai/knowledge-base-items), and can call the tools you expose through [connectors](/ai/connectors).
## What you can do
Primo AI works across the whole platform. You can ask it to:
* **Find information** — "Which devices are non-compliant?", "List employees with no assigned device."
* **Summarize** — a specific employee, device, or a period of onboardings and offboardings.
* **Report** — "Generate a fleet health report", "Do a SOC 2 audit."
* **Act** — perform tasks in Primo or in a connected system, with your approval.
## Capabilities
Beyond answering questions, Primo AI can:
* **Search the web** — pull in current information from outside Primo.
* **Create files** — generate documents and exports from your request.
* **Build HTML reports** — produce a formatted report you can preview in the chat.
* **Read your attachments** — accept PNG images, PDFs, and other files you send.
* **Remember context** — carry memory across a conversation so you can build on earlier answers.
## Open the assistant
Primo AI is available from every page. Click the **Chat** icon in the top bar to open the chat panel.
The panel adapts to your current page and offers ready-made suggestions for that context, for example:
| Page | Example suggestions |
| --------------- | --------------------------------------------------------------------------------------- |
| Devices | "Which devices are non-compliant?", "List devices with no assigned owner" |
| Onboardings | "Which onboardings are behind schedule?", "List new joiners missing a device this week" |
| Offboardings | "Which offboardings still have a device to collect?" |
| Employee detail | "Summarise this employee", "Is this employee fully onboarded?" |
Click a suggestion to send it, or type your own request.
## Add context
Type `@` in the message box to attach context to your question — a [connector](/ai/connectors) or a [knowledge base item](/ai/knowledge-base-items).
You can also attach files. Click **Attach files** and select the documents or images you want the assistant to consider.
## How it works
Primo AI combines several sources when it answers:
* **All your Primo data** — employees, devices, orders, SaaS, tickets, and more.
* **Page context** — the record or list you are viewing.
* **Knowledge base items** — your published skills and policies. See [Knowledge base items](/ai/knowledge-base-items).
* **Connectors** — tools from any connected MCP server. Use the **Connectors** control in the message box to choose which connectors are active for a conversation. See [Connectors](/ai/connectors).
## Approve actions
When a request requires a tool that writes or changes data, the assistant asks for confirmation first. Review the action, then click **Accept** to run it or **Cancel** to stop.
## Data security and privacy
Primo processes your data only to provide the service, as a processor under a Data Processing Agreement (DPA).
To power its AI features, Primo sends the data needed to answer your request to its model providers, Anthropic and OpenAI. In that context:
* The providers **never use your data to train** their models.
* The providers **delete your data within 15 days**.
* **Standard Contractual Clauses (SCCs)** cover transfers outside the EU.
Our DPA publishes the full list of sub-processors, including AWS, Anthropic, and OpenAI.
## Manage conversations
Primo AI saves each chat as a conversation. Open the conversations menu to revisit past threads, rename them, or start a new one.
# Automate your onboardings
Source: https://docs.getprimo.com/employees/automate-onboardings
Configure Primo to automatically handle the full onboarding journey — employee creation, email provisioning, SaaS access, and device enrollment — so every new hire starts on day one with everything they need.
**Prerequisite:** Automating onboardings requires your HR system to be connected so that Primo can detect upcoming arrivals and their start dates. See [Set up HR Sync](/employees/set-up-hr-sync).
Once configured, onboardings are triggered automatically based on contract start dates. Each step below corresponds to a configuration step in **Settings > Onboardings**.
## Step 1 — Employee information
Configure how employee profiles are created.
**Processing options:**
* **Manually** — employee profiles are created manually by an admin.
* **Automatically process** ✦ Recommended — Primo automatically creates employee profiles from their HR data as soon as they appear in the sync.
## Step 2 — Email address
This step requires Google Workspace or Microsoft Entra to be connected, and the **email provider** toggle to be turned on. See [Connect your email provider](/saas/get-started/connect-email-provider).
Configure how work email addresses are created for new employees.
### Email creation
Choose whether Primo should create the work email address:
* **Create with Primo** — Primo creates the email address in your connected provider (Google Workspace or Entra). If an email with the same address already exists, Primo will not create a duplicate.
* **Do not create** — email creation is handled outside of Primo.
### Password delivery
Choose who receives the employee's initial password:
* **Send to manager** — the manager defined on the employee profile receives the password.
* **Send to an admin** — a designated Primo administrator receives the password.
* **Send to employee** — the new employee receives the password directly.
### Scheduling
Choose how many days before the onboarding date email addresses should be created. Default: one week before at 07:00.
### Processing options
* **Manually** — email accounts are created manually by an admin.
* **Automatically process** ✦ Recommended — Primo automatically creates email accounts for employees with upcoming onboarding dates based on the schedule above.
* **Automatically skip** — email creation is skipped entirely for all onboardings.
## Step 3 — SaaS provisioning
Configure how SaaS application access is granted at onboarding.
### Scheduling
Choose how many days before the onboarding date accounts should be provisioned. Default: one day before at 18:00.
### AI suggestions
When enabled, Primo uses AI to suggest the right SaaS applications, groups, roles, and licences for each new employee based on their role, team, and manager.
### Processing options
* **Manually** — SaaS provisioning is handled manually by an admin.
* **Automatically process** ✦ Recommended — Primo automatically provisions onboarding employees in connected SaaS applications based on the schedule and rules above.
* **Automatically skip** — SaaS provisioning is skipped entirely for all onboardings.
## Step 4 — Equipment
Configure when equipment is ordered for, or assigned to, new employees.
**Coming soon:** Automatic equipment ordering is on the roadmap. Today, equipment assignment must be handled manually or skipped.
**Processing options:**
* **Manually** — equipment is assigned manually by an admin.
* **Automatically skip** — the equipment step is skipped entirely for all onboardings.
## Step 5 — MDM enrollment
Configure whether employees are automatically enrolled in MDM at onboarding.
**Enroll employees in MDM invites** — when enabled, Primo automatically sends an MDM enrollment invitation to new employees on their onboarding date. Primo will resend the invitation every 7 days until the agent is installed.
For zero-friction day-one setup, combine MDM enrollment with Zero Touch Deployment — devices arrive pre-enrolled and ready to use. See [Zero Touch for Mac](/mdm/zero-touch/zero-touch-macs) or [Zero Touch for Windows](/mdm/zero-touch/zero-touch-windows).
## Step 6 — Custom AI agents
*Coming soon* — Build custom AI agents that run at onboarding — automatically send a welcome Slack message, create a Notion onboarding page, open a Jira ticket, or trigger any workflow in your stack.
## Related articles
* [Set up HR Sync](/employees/set-up-hr-sync)
* [Automate your offboardings](/employees/automated-offboardings)
* [Rules (SaaS provisioning)](/saas/licence-provisioning)
# Automate your offboardings
Source: https://docs.getprimo.com/employees/automated-offboardings
Configure Primo to automatically handle the full offboarding journey — SaaS deprovisioning, email suspension, and equipment retrieval — triggered by departure dates from your HR system.
**Prerequisites:**
* Your HR system must be connected so that Primo can detect departure dates. See [Set up HR Sync](/employees/set-up-hr-sync).
* The **contract end date** field must be set to **Continuous synchronization** in your HR system settings — otherwise departure date changes won't be picked up automatically.
**Coming soon:** Full offboarding automation — including one-click deprovisioning across all connected apps, automated equipment return, and MDM wipe — is on the roadmap. The steps below cover what's configurable today.
Once configured, offboardings are triggered automatically when a departure date arrives. Each step below corresponds to a configuration step in **Settings > Offboardings**.
## Step 1 — Deprovisioning
Configure when and how employee SaaS access is revoked at offboarding.
This step requires Google Workspace or Microsoft Entra to be connected, and the **email provider** toggle to be turned on. See [Connect your email provider](/saas/get-started/connect-email-provider).
### Scheduling
Choose when accounts should be deprovisioned relative to the employee's last day. Default: the day of departure (D-day) at 19:00.
When triggered, Primo deprovisions access to all connected SaaS applications using SCIM or API integrations. For Google Workspace and Microsoft Entra, this also suspends the employee's account and can transfer data (Drive files, email ownership) to a designated recipient.
### Processing options
* **Manually** — deprovisioning is triggered manually by an admin.
* **Automatically process** ✦ Recommended — Primo automatically deprovisions access based on the schedule above.
* **Automatically skip** — the deprovisioning step is skipped entirely for all offboardings.
## Step 2 — Equipment
Configure when device offboarding actions are scheduled relative to the employee's last day.
### Scheduling
Choose when device offboarding actions should run. Default: the day of departure (D-day) at 19:00.
Device offboarding actions include:
* Sending a return shipment label to the employee
* Triggering an MDM unenrollment command
* Moving the device back to stock or archiving it
It is recommended to wipe a device before reassigning it. See [Wiping devices](/mdm/guides/wiping-devices).
### Processing options
* **Manually** — equipment offboarding actions are triggered manually by an admin.
* **Automatically process** ✦ Recommended — Primo automatically triggers equipment offboarding actions based on the schedule above.
* **Automatically skip** — the equipment step is skipped entirely for all offboardings.
## Related articles
* [Set up HR Sync](/employees/set-up-hr-sync)
* [Automate your onboardings](/employees/automate-onboardings)
* [Connect your email provider](/saas/get-started/connect-email-provider)
* [Wiping devices](/mdm/guides/wiping-devices)
# Set up HR Sync
Source: https://docs.getprimo.com/employees/set-up-hr-sync
Connect your HR system to Primo to automatically sync employee data, trigger onboarding and offboarding workflows, and keep your employee directory up to date. If you don't use an HR system, you can import employees via CSV.
Syncing your HR system with Primo lets you automate onboardings and offboardings, build IT policies based on HR data (teams, roles, entities), and keep your employee directory accurate without manual work.
## Connect your HR system
You can connect one or several HR system sources to the same Primo account — useful if your organization uses different HR tools by country or legal entity.
Primo needs a few core fields to function — first name, last name, professional email, start/end dates, team, manager, etc.
You can turn off synchronization for the following fields if you prefer not to share personal data:
| Field | Used for | Can be turned off? |
| ----------------------- | ---------------------------------- | ------------------ |
| Personal email | Alternative contact for enrollment | ✅ |
| Personal phone | Alternative contact | ✅ |
| Personal postal address | Shipping equipment to employees | ✅ |
You can restrict which employees are synchronized:
* Selected legal entities
* Specific contract or employment types
* Selected teams
Filters help ensure only relevant employees are managed.
Once connected, employees sync into Primo with their associated metadata (contract dates, teams, roles). Data is refreshed automatically every hour.
## Connection guides
Primo uses [Kombo](https://www.kombo.dev/) to connect to HR systems. If you're looking for a step-by-step connection guide for your specific provider, Kombo maintains detailed guides for every supported integration at [help.kombo.dev](https://help.kombo.dev/hc/en-us/sections/14349683218961-Connection-Guides).
Direct links to the most commonly used providers:
* [BambooHR](https://help.kombo.dev/hc/en-us/articles/17797240347921-BambooHR-HRIS-How-do-I-link-my-account)
* [BoondManager](https://help.kombo.dev/hc/en-us/articles/25156761925137-BoondManager-How-do-I-link-my-account)
* [CezanneHR](https://help.kombo.dev/hc/en-us/articles/23272427261713-CezanneHR-How-do-I-link-my-account)
* [Lucca](https://help.kombo.dev/hc/en-us/articles/19686865697681-Lucca-HRIS-How-do-I-link-my-account)
* [Payfit](https://help.kombo.dev/hc/en-us/articles/20233940964241-Payfit-How-do-I-link-my-account#h_01GZ1PZGF5SW8EVSHF2B1T9X5D)
## Synchronization frequency & modes
Once connected, data is automatically synchronized every hour. No manual action is required.
For each synchronized field, you can choose:
* **Import once** — the field is set on first sync and can then be managed manually.
* **Continuous synchronization** — the field stays in sync with the HR system and cannot be edited manually.
Examples:
* Contract start and end dates → continuous synchronization (required for automated offboarding)
* Job title → import once, then maintain manually
For automated offboarding to work correctly, the departure/contract end date field must be set to **Continuous synchronization**.
### Handle external employees
Some HR systems include individuals outside your core workforce (contractors, consultants). To exclude them from your employee directory:
1. Open the employee profile and click **Hide**.
2. If they appear in the Onboardings list, you can also **Ignore** the onboarding — this hides the employee without fully deleting the record.
Hidden employees are excluded from employee management workflows.
## Troubleshoot HR sync
### Investigate a missing onboarding employee
1. Verify the employee exists in your HR system with a **start date** set.
2. Check both active employees (including hidden) and the Onboardings list — remove all filters.
3. Review what Kombo has retrieved: Go to **Settings > Employee Sync > \[your HR system] > Update settings > Employee filtering > Preview**.
* **Included** — the employee is in the sync. Search by last name in active employees, onboardings, and offboardings.
* **Excluded** — Kombo shows the reason (often a filter). Update filters to include the employee.
### Investigate a missing offboarding employee
If an employee doesn't appear in the Offboardings view:
1. Go to **Settings > Employee Sync**.
2. Review the **offboarding or contract end date** field configuration.
3. Ensure it is set to **Continuous synchronization** (not Import once).
# Track onboardings as tickets
Source: https://docs.getprimo.com/employees/track-onboardings-as-tickets
Follow and resolve every employee onboarding from a single ticket, where each onboarding step appears as a task you can configure, schedule, or skip.
Every employee onboarding is backed by a ticket. The onboarding steps — HR information, email, SaaS provisioning, and equipment — appear as tasks on that ticket, so you follow, comment on, and resolve the full journey from one place.
This article covers how to **track** an onboarding once it exists. To configure how each step is processed (manual, automatic, or skipped), see [Automate your onboardings](/employees/automate-onboardings).
## How an onboarding becomes a ticket
Each onboarding creates a ticket automatically:
* **From HR sync** — when your HR system reports an upcoming arrival, Primo creates the onboarding and its ticket together, starting with the **Onboarding details** task.
* **From manual creation** — when you create an onboarding manually, the ticket appears once you validate the HR information step. Your onboarding settings determine the remaining tasks.
The ticket title uses the new employee's name (for example, *John Doe - Onboarding*) and the ticket goes to the employee's direct manager when one is set. The new employee becomes the ticket requester, and related items such as equipment orders link to the ticket as related objects.
## Where to find onboarding tickets
Open the employee profile and go to the **Tickets** tab to see the onboarding ticket and its status. You can also find it from the main **Tickets** list. Open the ticket to view its tasks and full activity log.
## Onboarding tasks
The ticket groups tasks by how you handle them:
* **Manual tasks** — need a human action before completion.
* **Scheduled tasks** — run automatically on a due date (for example, *Provision Slack — Scheduled for 28 Jun*).
* **Done tasks** — already completed.
Each onboarding step maps to a task:
| Onboarding step | Task on the ticket | How it's completed |
| ----------------------------- | ------------------------- | ------------------------------------------------ |
| HR information | Onboarding details | **Go to stepper** opens the step |
| Email | Create professional email | **Go to stepper** opens the step |
| Equipment | Configure equipment | **Go to stepper** opens the step |
| SaaS provisioning (automatic) | Provision | Runs automatically on its scheduled date |
| SaaS provisioning (manual) | Create account for on | **Mark as done** once you've created the account |
Tasks appear only for the steps your onboarding settings include.
### Edit a task from the list
Each task row is a compact action bar you can use without opening the task:
* **Manual tasks** — change status, priority, tags, or assignee directly from the row. Tag changes accumulate while the menu is open and save when you close it. Click **✓** to mark the task done, or **⋯** for more options.
* **Onboarding and offboarding steps** — set the priority inline. Status stays read-only because the stepper owns it: use the **→** button to jump to the matching stepper step, or **⋯** to view details, view logs (per-SaaS provisioning), edit, or cancel.
Clicking anywhere else on the row opens the task detail page for manual tasks, or the stepper step for onboarding and offboarding steps.
### Complete a task
Each task shows a contextual action depending on its type:
* **Go to stepper (→)** — for onboarding steps (HR information, email, equipment). It opens the matching step; completing the step marks the task as done.
* **Mark as done (✓)** — for SaaS accounts you create manually, and for manual tasks. Create the account in the application, then mark the task done.
* No action — automatically provisioned SaaS tasks run on their scheduled date and complete on their own.
Completing onboarding steps through **Go to stepper** keeps the ticket and the onboarding in sync: the task status always follows the step.
## Skip a step or cancel the onboarding
* **Skip a step** — from a task's menu, skip a step you don't need for this employee. Skipping a step cancels its task, and cancelling a task skips the step — it's the same action from two entry points.
* **Cancel the onboarding** — available while the onboarding hasn't started yet (status **To-do**), for example right after an HR sync created it. Cancelling the onboarding cancels the ticket and all its pending tasks. Primo keeps already-completed tasks for history.
## Ticket status
The ticket status reflects onboarding progress automatically:
* A new onboarding ticket starts as **To-do**.
* Completing a task while others remain moves the ticket to **In progress**.
* Completing the last task moves the ticket to **Done**.
* Cancelling the onboarding moves the ticket to **Cancelled**.
## Related articles
* [Automate your onboardings](/employees/automate-onboardings)
* [Set up HR Sync](/employees/set-up-hr-sync)
* [Automate your offboardings](/employees/automated-offboardings)
# Welcome to Primo
Source: https://docs.getprimo.com/index
Everything you need to manage your company's IT — devices, MDM, procurement, and SaaS — all in one place.
Sync your HR system, automate onboarding and offboarding, and manage your employee directory.
Enroll devices, push policies, manage software, and keep your fleet secure.
Track applications, manage licences, and automate user provisioning.
Deploy CrowdStrike, SentinelOne, or ThreatDown to protect every endpoint.
Order equipment worldwide, manage shipments, and track warranties.
Authenticate with the Primo REST API and connect your tools via the MCP server.
# Glossary
Source: https://docs.getprimo.com/introduction/glossary
A reference for the IT and product terminology you'll encounter throughout the Primo Help Center.
**Access Control** – The practice of restricting access to resources based on defined rules or roles. Primo enforces access control across devices, SaaS applications, and the admin console.
**Admin** – A user with elevated permissions in Primo who can manage devices, employees, policies, and settings on behalf of the organization.
**Agent** – A lightweight software component installed on a managed device that communicates with the Primo platform to enforce policies and report status.
**API (Application Programming Interface)** – A set of protocols that allows external systems to interact with Primo programmatically. See [Create a Primo API key](/api/create-primo-api-key).
**API Key** – A credential used to authenticate requests to the Primo REST API. Primo supports both company-level and fleet-level API keys.
**Audit Log** – A chronological record of actions taken within the Primo platform — including policy changes, device enrollments, and user access events — for compliance and troubleshooting.
**Authentication** – The process of verifying the identity of a user or device before granting access to a system or application.
**Autopilot** – Microsoft's zero-touch deployment program for Windows devices, integrated with Primo for automated enrollment and configuration at first boot.
**Automation** – A configured workflow in Primo that triggers actions automatically — such as provisioning SaaS accounts at onboarding or revoking access at offboarding.
**Bypass Code** – A recovery code used to unlock a device when the standard authentication method is unavailable (e.g., Activation Lock bypass on Apple devices).
**Certificate** – A digital credential used to authenticate devices or users, often deployed via MDM to enable secure Wi-Fi, VPN, or identity provider access.
**Compliance** – The state of a device or user meeting the security and configuration requirements defined by your organization's policies.
**Cost Optimization** – The process of identifying and eliminating waste in SaaS spending — such as unused licences or duplicate subscriptions — surfaced through Primo's SaaS Management.
**Deployment** – The process of distributing software, configurations, or device profiles to managed endpoints, typically via MDM.
**Device** – Any endpoint managed by Primo — including Mac, Windows, Linux, iOS, Android, and iPadOS devices.
**Device Management** – The practice of centrally enrolling, configuring, securing, and monitoring company devices. See [Platform support](/mdm/get-started/supported-platforms).
**Directory** – A centralized store of user identities and their associated attributes, used to manage access across applications. Common examples: Google Workspace, Microsoft Entra ID.
**Directory Service** – A service (such as Google Workspace or Entra ID) that acts as the authoritative source for user identities and group memberships.
**EDR (Endpoint Detection & Response)** – Security software that monitors endpoints for threats and provides response capabilities. Primo integrates with CrowdStrike Falcon, SentinelOne, and ThreatDown.
**Encryption** – The transformation of data into an unreadable format to prevent unauthorized access. Primo can enforce full-disk encryption (FileVault on Mac, BitLocker on Windows) via MDM policy.
**Endpoint** – Any device that connects to a corporate network or accesses company resources — laptops, desktops, smartphones, and tablets.
**Enrollment** – The process of registering a device into Primo's MDM, enabling centralized management and policy enforcement.
**Fleet** – The collective set of devices managed by an organization within Primo.
**HRIS (Human Resources Information System)** – A platform that stores employee data. Primo can sync with your HRIS to automatically trigger onboarding and offboarding workflows.
**Identity** – A digital representation of a user, comprising their credentials, attributes, and access rights across systems and applications.
**Identity & Access Management (IAM)** – A framework for managing digital identities and controlling access to resources. Primo's SaaS Management module provides IAM capabilities.
**Identity Provider (IdP)** – A service that authenticates users and provides identity assertions to other applications via protocols like SAML or OIDC. Examples: Google Workspace, Microsoft Entra ID.
**Integration** – A connection between Primo and a third-party application or service that enables data exchange or automated actions.
**Just-in-Time (JIT) Provisioning** – A mechanism that automatically creates a user account in an application at the moment of their first login via SSO, without prior manual setup.
**Least Privilege** – A security principle requiring that users and systems are granted only the minimum permissions necessary to perform their role.
**Licence** – An entitlement to use a software product or service, typically tied to a user seat. Primo tracks licence consumption and can automate assignment and revocation.
**Lifecycle Management** – The end-to-end management of an employee's IT access and equipment — from onboarding to offboarding.
**MDM (Mobile Device Management)** – A technology that allows organizations to remotely enroll, configure, monitor, and secure devices. Primo's MDM supports Mac, Windows, Linux, iOS, and Android.
**MDM Control / Policy** – A configuration rule deployed to managed devices via MDM — such as enforcing encryption, blocking USB storage, or managing installed applications.
**MFA (Multi-Factor Authentication)** – An authentication method requiring users to verify their identity with two or more factors (e.g., password + authenticator app).
**Offboarding** – The process of revoking an employee's IT access, recovering their equipment, and deprovisioning their accounts when they leave the organization.
**Onboarding** – The process of setting up IT access, provisioning accounts, and configuring devices for a new employee joining the organization.
**Policy** – A set of rules enforced on managed devices or users — covering security settings, application access, and compliance requirements.
**Policy Enforcement** – The automated application of policy rules to devices and users, ensuring compliance without manual intervention.
**Provisioning** – The creation and configuration of user accounts, licences, or resources — typically triggered automatically at onboarding.
**recoveryOS** – Apple's built-in recovery environment, accessible during Mac startup. Primo can use recoveryOS protections to prevent unauthorized reinstallation.
**Role-Based Access Control (RBAC)** – An access management approach where permissions are assigned based on a user's role within the organization.
**SaaS (Software as a Service)** – Cloud-based applications delivered over the internet on a subscription basis (e.g., Slack, Notion, Google Workspace).
**SaaS Stack** – The full set of SaaS applications used by an organization, managed and tracked in Primo's SaaS module.
**SAML (Security Assertion Markup Language)** – An open standard for exchanging authentication and authorization data between identity providers and service providers, enabling SSO.
**SCIM (System for Cross-domain Identity Management)** – A protocol that automates the provisioning and deprovisioning of user accounts across applications, triggered by your identity provider.
**SecureToken** – An Apple mechanism required for enabling FileVault encryption and certain admin operations on macOS. Primo can manage SecureToken assignment.
**Security** – The practice of protecting devices, data, and access through policies, monitoring, and automated controls — a core capability of the Primo platform.
**Shadow IT** – Applications used by employees without IT's knowledge or approval. Primo's SaaS Discovery helps identify and govern shadow IT.
**Single Sign-On (SSO)** – An authentication method that allows users to access multiple applications with a single set of credentials, reducing password fatigue and improving security.
**SSO Tax** – A pricing practice where SaaS vendors charge a premium to unlock SSO or SCIM features, treating enterprise security as an add-on.
**Subscription** – A recurring payment for access to a SaaS product or service, tracked and managed within Primo's SaaS module.
**Synchronization** – The automated process of keeping employee data, device states, or SaaS user records consistent between Primo and connected systems.
**Token** – A credential or identifier used to authenticate a session or API request.
**Unenroll** – The process of removing a device from Primo's MDM management, after which policies and profiles are no longer enforced.
**User Management** – The administration of user accounts, credentials, and access rights — including password policies, admin account management, and local user control.
**Zero Touch** – A deployment method where devices are automatically enrolled and configured without any IT intervention required at the device. See [Zero-touch deployment](/mdm/zero-touch/understand-zero-touch).
**Zero Trust** – A security model that assumes no user or device should be inherently trusted, requiring continuous verification of identity and device posture before granting access.
# Audit logs
Source: https://docs.getprimo.com/mdm/audit-logs
Track all administrative actions taken on devices and MDM settings in Primo — including policy changes, remote commands, and enrollment events.
The MDM Audit Log records all administrative actions performed in the Device Management section of Primo, including:
* Policy and profile changes
* Remote commands (wipe, lock, unenroll)
* Enrollment and unenrollment events
* Software deployment actions
* Settings modifications
## Access the audit log
1. Go to **Devices > Audit Logs**.
2. Filter by date range, action type, or administrator.
3. Export to CSV for compliance reporting.
For questions about audit log retention or export, contact [support@getprimo.com](mailto:support@getprimo.com).
# Compliance alert reference
Source: https://docs.getprimo.com/mdm/compliance/alert-reference
What each compliance alert status means, why macOS and Windows devices trigger it, and how to bring them back to a compliant state.
This reference explains every alert status you can encounter on the **MDM > Compliance Alerts** page: what the device is actually reporting, the causes behind it on macOS and Windows, and how to resolve it. To choose which statuses raise alerts, see [Configure compliance alert rules](/mdm/compliance/alert-rules); for the triage workflow itself, see [Monitor compliance alerts](/mdm/compliance/alerts).
Mobile platforms (iOS, iPadOS, Android) and Linux are covered by a subset of these rules — see [Supported platforms](/mdm/get-started/supported-platforms) for what applies where.
## How Primo decides a device is non-compliant
* Every time a device syncs, Primo re-runs each compliance rule and computes a status per rule — there is no separate scan.
* A device alerts only if its current status is one you toggled on in **Manage rules**. A rule with no statuses toggled never alerts.
* Alerts clear automatically on the next sync once the status improves. There is no manual acknowledge or close.
See [Compliance overview](/mdm/compliance/overview) for the full evaluation model.
## Rule out stale data first
A compliance status is a snapshot from the device's **last sync**. Before treating an alert as a real violation, check whether the data is stale:
| Situation | What you see | What is actually happening |
| ----------------------------------------- | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Device offline or asleep | Any status, frozen | The device keeps its last reported status until it syncs again. Fix the connectivity first — the other alerts may clear on their own. |
| Device enrolled minutes ago | `PENDING` on several rules, `NOT_ENCRYPTED` | Controls apply progressively after enrollment — profile-delivered rules report `PENDING` until the device applies them. On macOS, FileVault only takes effect after the next restart, and the recovery key can take up to 24 hours after that restart to escrow. |
| Enrollment action just performed | Enrollment alert still visible | Enrollment status changes take up to **30 minutes** (the synchronization period) to reflect in the dashboard. |
| Windows device late on an update | `GRACE_PERIOD` | The device is inside the grace window you configured. No action is needed until the window ends. |
| Every SentinelOne device alerting at once | `NOT_PROTECTED` fleet-wide | The SentinelOne service user token has expired: the integration stops syncing and protection statuses go stale. Renew the token in **Settings > Integrations > SentinelOne**. |
| Persistent low-value alerts | `OFFLINE` on healthy devices | The rule is stricter than your reality. Alert on **Offline 7+ days** instead of **Offline** — short check-in gaps are normal. |
## Enrollment Status
A global rule that applies to every managed device. It checks whether the device is fully enrolled and whether the MDM agent still communicates with the server.
| Status | Meaning |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------- |
| `MDM_OFF` | The device is not enrolled or MDM is inactive. |
| `MISSING_AGENT` | The agent is installed but no longer sending data to the server. |
| `MDM_ON_IN_ANOTHER_MDM` | The device is currently managed by a different MDM. |
| `READY_ZTD` | The device is configured and waiting for Zero-Touch Deployment. Expected for in-stock devices — not an incident. |
### Why devices drift out of enrollment
Causes that apply to both platforms:
* The employee did not complete all the enrollment steps, or did not stay connected long enough to finish synchronization.
* The agent was uninstalled manually, or a system update or configuration error corrupted the installation.
* The `osqueryd` service used by the agent has stopped, or the agent fails to start due to permission issues.
* The device sits on a network that blocks access to the MDM server — a proxy or firewall cuts the communication. See [Network requirements](/mdm/network-requirements).
- An admin user can remove an **unlocked MDM profile** from System Settings. The device then reports `MDM_OFF` even though the agent may still respond.
- An expired or revoked **APNs token** prevents the device from validating its profile — the profile becomes invalid without anyone touching the device.
- A `turn off mdm` action executed from the MDM server side removes management.
- The Fleet agent installation is incomplete — the most common cause of partial enrollment on macOS.
* The device is still enrolled in a previous MDM and reports `MDM_ON_IN_ANOTHER_MDM` — migrate it out of the old MDM before re-enrolling.
* A proxy or corporate firewall blocking the server connection leaves an installed agent silent (`MISSING_AGENT`).
### Resolve enrollment alerts
* **`MISSING_AGENT`** — in the device panel, click the device status button to remotely trigger the agent installation. If that fails, ask the employee to open their Primo enrollment page, click their assigned device, and download the agent.
* **`MDM_ON_IN_ANOTHER_MDM`** — migrate the device from the previous MDM first.
* **`MDM_OFF`** — ask the employee to re-enroll. You can automate this: in **Settings > MDM**, enable **Auto-Unenrollment** and the option to automatically resend MDM invitations to employees whose devices were purged.
Allow up to 30 minutes for the status to update after the fix. Full detail: [Resolve enrollment issues](/mdm/guides/resolve-enrollment-issues).
## Online Status
A global rule tracking whether the device checks in with the server.
| Status | Meaning |
| ---------------- | ------------------------------------------------- |
| `OFFLINE` | The device missed its recent check-ins. |
| `OFFLINE_7_DAYS` | The device has not checked in for 7 days or more. |
### Why devices go offline
* The device is powered off or asleep — an employee on leave, or a spare sitting in a drawer.
* The network blocks the agent's connection to the server (VPN, proxy, firewall rules). See [Network requirements](/mdm/network-requirements).
* The agent is no longer running. A device that appears offline **while actively used by an employee** typically indicates a missing agent or a network issue, not a genuinely offline device — check the Enrollment Status alert for the same device.
### Resolve online alerts
Confirm with the employee whether the device is in use. If it is, treat it as a `MISSING_AGENT` case (see above). If the noise comes from short gaps, alert on **Offline 7+ days** only.
## Platform support
A global rule that checks the device's OS against the baseline Primo supports as an MDM signal source. A device below that baseline cannot reliably enroll, report telemetry, or honor policies — this alert is your upgrade list.
| Status | Meaning |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------ |
| `BELOW_MINIMUM_VERSION` | The OS version is older than the minimum Primo supports on that platform. |
| `UNSUPPORTED_OS_EDITION` | The OS edition is not supported — typically Windows Home / Family, which cannot run BitLocker or most security policies. |
`MEETS_REQUIREMENTS` is the compliant status. The rule stays silent until the device has reported its OS information, so a freshly enrolled device is never flagged as unknown.
### Resolve platform support alerts
* **`BELOW_MINIMUM_VERSION`** — upgrade the OS. The current baselines per platform are listed in [Supported platforms](/mdm/get-started/supported-platforms).
* **`UNSUPPORTED_OS_EDITION`** — upgrade the edition, not just the version: see [Manage Windows Home devices](/mdm/policies/manage-windows-home) and [Upgrade to Windows 11](/mdm/guides/upgrade-windows-11).
## Encryption
Checks full-disk encryption: **FileVault** on macOS, **BitLocker** on Windows. Encryption is not on by default — it starts when you enable the **Disk Encryption** control, which applies globally to enrolled devices once created.
| Status | Meaning |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| `NOT_ENCRYPTED` | The disk is not encrypted. |
| `ACTION_REQUIRED` | The control is waiting on the employee — typically entering their login password so the recovery key can be generated and escrowed. |
| `MISSING_RECOVERY_KEY` | The disk is encrypted, but Primo holds no recovery key for it. |
`ENCRYPTED` is the compliant status. iOS and iPadOS devices always report `ENCRYPTED` — their storage is hardware-encrypted by design. A Windows Home device raises no encryption status at all: it cannot run BitLocker and surfaces under [Platform support](#platform-support) as `UNSUPPORTED_OS_EDITION` instead.
* FileVault turns on once the Disk Encryption control targets the device, but **encryption only takes effect after the next restart**. A Mac that never restarts stays `NOT_ENCRYPTED` — ask the employee to reboot.
* The recovery key is escrowed **within 24 hours after that restart**. A freshly encrypted Mac showing `MISSING_RECOVERY_KEY` in that window resolves on its own.
* A Mac **encrypted before enrollment** has a key Primo never saw — escrow is not retroactive. The employee must enter their password when prompted so a new key can be generated and escrowed (`ACTION_REQUIRED`).
* BitLocker starts encrypting as soon as the control reaches the device, with no restart required, and the key is stored as soon as encryption activates. A Windows device stuck on `NOT_ENCRYPTED` usually has a blocker, not a delay.
* BitLocker needs a working **TPM**. A missing or firmware-disabled TPM makes encryption fail to start.
Control details: [Disk encryption](/mdm/policies/disk-encryption).
## OS Update
Checks that devices install required OS updates by the deadline you enforce.
| Status | Meaning |
| ---------------- | --------------------------------------------------------------------------------------------------------- |
| `NOT_UP_TO_DATE` | A required update is past its deadline and not installed. |
| `GRACE_PERIOD` | Windows only — the device is late but inside the grace window you configured before forced restart. |
| `PENDING` | The update policy itself has not been applied by the device yet — the same delivery state as any profile. |
`UP_TO_DATE` is the compliant status. Between an update's release and its deadline, the device stays compliant — `NOT_UP_TO_DATE` only fires once the deadline has passed. A device whose OS is too old for Primo itself is a [Platform support](#platform-support) alert, not an OS Update one.
### Why devices fall behind on updates
* **The deadline counts from the update's availability date, not from when you configured the policy.** Enabling the policy on a fleet running older versions flags those devices immediately — expect a wave of alerts on day one.
* **Low disk space** blocks the update on every platform, and none of them frees space automatically. On macOS 14+ the employee sees a system notification; on macOS 13 and earlier the Nudge window keeps reappearing while the download fails; on Windows the employee is told the update failed. An administrator may need to step in.
* **The device was off when the deadline passed.** On macOS 14+ the update is scheduled for 1 hour after it turns back on; on Windows the employee gets the configured grace period before the automatic restart.
* The employee keeps deferring within the allowed window — pressure increases as the deadline approaches (hourly notifications 24 hours before, more frequent in the final hour).
### Resolve update alerts
Have the employee free disk space if that is the blocker, then let the enforcement flow run — it escalates on its own. Details and the exact notification schedule per platform: [Enforce OS updates](/mdm/policies/enforce-minimum-os-version).
## Endpoint protection (SentinelOne, ThreatDown)
Available once the corresponding integration is connected. Checks that the endpoint protection agent is installed and reporting.
| Status | Meaning |
| ---------------- | ------------------------------------------------------------------------------------ |
| `NOT_PROTECTED` | The protection agent is not installed, not running, or not reporting on this device. |
| `OFFLINE_7_DAYS` | ThreatDown only — the agent has not reported to the console for 7 days or more. |
`ACTIVE` is the compliant status for both tools.
### Why devices show as unprotected
* The control was just enabled — the agent installs on the device's next sync.
* The agent was uninstalled locally or is not running.
* **The integration itself is stale.** SentinelOne service user tokens expire; once the token lapses, syncing stops and protection statuses go stale fleet-wide. Renew the token in **Settings > Integrations > SentinelOne**.
* The device is offline, so its real protection state is unknown.
Setup and remediation: [SentinelOne](/mdm/endpoint-protection/sentinelone), [ThreatDown](/mdm/endpoint-protection/threatdown).
## Admin accounts (Admin User Management, Admin Password Rotation)
Checks that the managed local administrator account exists, holds the expected privileges, and rotates its password on schedule.
| Status | Meaning |
| ------------------ | ------------------------------------------------------------------------------------------------ |
| `CREATION_PENDING` | The admin account creation was sent but the device has not applied it yet. |
| `CREATION_FAILED` | The device could not create the account — for example, the username already exists locally. |
| `DEMOTION_PENDING` | **Demote non-matching accounts** is enabled, but one or more accounts have not been demoted yet. |
### Why admin account actions stall
* `CREATION_PENDING` on an offline device resolves once it syncs.
* On macOS, demotion waits until the **Primo-managed admin account itself holds a SecureToken** — the token FileVault depends on. Primo deliberately demotes nobody before that, so the device is never left without a token-holding admin, and `DEMOTION_PENDING` persists (the device logs the event `ADMIN_DEMOTION_BLOCKED_SECURE_TOKEN_NOT_GRANTED`). The managed admin receives its token at its **first login** on the device — have someone log into that account once, or grant the token manually. See [SecureToken rules](/mdm/policies/secure-token).
* The dashboard can take up to 24 hours to refresh the local account status in the device's **Users** tab — verify on the device before concluding a failure.
The **Admin Password Rotation** rule reports its own statuses: `PENDING`, `SUCCESS`, `ERROR`. `SUCCESS` is compliant; `PENDING` clears once the device applies the rotation, so `ERROR` is the status worth alerting on.
Control details: [Admin management](/mdm/policies/manage-admin-accounts).
## iCloud Lock (Activation Lock)
**macOS only** — Activation Lock also exists on iOS and iPadOS, but this compliance rule only evaluates Macs. It checks that when Activation Lock is on, Primo holds the bypass code, so the device can be recovered after a wipe without the employee's Apple Account.
| Status | Meaning |
| --------------------- | --------------------------------------------------------------- |
| `MISSING_BYPASS_CODE` | Activation Lock is on, but no bypass code is escrowed in Primo. |
`ENABLED` (lock on, code escrowed) and `DISABLED` (lock off) are both compliant. The rule produces no status while the device is not fully enrolled or its lock state is still unknown.
### Why a bypass code is missing
Escrow happens at the moment Activation Lock activates — **it is not retroactive**. All of these must be true for the code to escrow:
* The device is supervised via MDM.
* The device was enrolled **before** Activation Lock was enabled. If the employee turned on Find My before enrollment, the code cannot be retrieved — the only recovery path is their Apple Account credentials.
* The device is company-owned (BYOD devices are not eligible).
* The MDM profile is installed at the system level (user-approved enrollment without ABM does not reliably escrow codes).
Scenario-by-scenario analysis and remediation: [Activation Lock bypass code escrow](/mdm/guides/activation-lock-bypass).
## Recovery OS
macOS only. Checks that the recoveryOS protection configuration is applied. Only **Apple Silicon** Macs are evaluated — Intel Macs cannot support recoveryOS protection and produce no status at all.
| Status | Meaning |
| --------- | ---------------------------------------------------------------------- |
| `PENDING` | The device has not applied the recoveryOS configuration yet. |
| `FAILED` | The device reported that the recoveryOS configuration failed to apply. |
`PROTECTED` is the compliant status. Full enforcement requires the device to be enrolled with the appropriate supervision level — an unsupervised Mac is the first thing to check on `FAILED`. Control details: [recoveryOS protection](/mdm/policies/recoveros-protection).
## Profile-delivered controls
Firewall, Password Policy, Wi-Fi, USB Blocking, App Blocking, Screen Capture, Disable AirDrop, Lock Profiles Pane, Google Chrome, Device Naming, Custom Configuration File, Web Clip, AirPrint, Software Update (macOS), and the SSO controls (Entra SSO, Okta SSO, Primo SSO) all work the same way: Primo delivers a configuration to the device, and the device reports back. They share the same delivery statuses:
| Status | Meaning |
| --------- | ------------------------------------------------------------------------- |
| `PENDING` | The configuration is on its way — the device applies it on the next sync. |
| `ERROR` | The configuration did not apply correctly on the device. |
`ENFORCED` is the compliant status.
### Why a configuration fails to apply
* An admin user removed the MDM profile carrying the configuration (unless **Lock Profiles Pane** prevents it).
* APNs issues stop the device from receiving or validating profiles — check the Enrollment Status alert for the same device.
* The control targets a capability the device lacks: Platform SSO controls require recent macOS versions (Primo SSO needs macOS 14+), and the employee must complete the identity provider registration prompt in their session.
* **Windows Home / Family** only partially applies security policies — several configurations require Pro, Enterprise, or Education, and fail without an explicit error on Home. See [Manage Windows Home devices](/mdm/policies/manage-windows-home).
* A conflicting setting from a previous MDM or a local group policy overrides the delivered value.
`PENDING` that persists usually means the device is offline — fix connectivity first. For `ERROR`, open the device drawer, jump to the related MDM control to verify its configuration, and re-apply.
## Remote Access (RustDesk)
Unlike the profile-delivered controls, the Remote Access rule tracks a **software installation**, not a configuration profile.
| Status | Meaning |
| --------- | ------------------------------------------------------ |
| `PENDING` | The RustDesk agent is not installed on the device yet. |
`INSTALLED` is the compliant status. A persistent `PENDING` usually means the device is offline or the installation is still queued — check the [software installation status](/mdm/software-installation-status) from the device panel, then let the next sync clear the alert.
## Resolve any alert: the general loop
Click the alert row on **MDM > Compliance Alerts**. Review the device's full status across every rule — several alerts on one device often share a single root cause (offline, agent missing, profile removed).
Check when the device last synced. If it has been offline, resolve connectivity before anything else.
Use the sections above. Remediation actions (push profile, lock, wipe) are available from the device drawer — see [Manage your devices](/mdm/guides/wiping-devices).
Alerts resolve automatically on the next device sync once the status improves. If an alert should never have fired, remove that status from the rule in **Manage rules** instead.
## Permissions
| Action | Permission |
| --------------------- | ----------- |
| View alerts and rules | `MDM_READ` |
| Edit alert rules | `MDM_WRITE` |
## Next steps
Choose which of these statuses count as a violation for your fleet.
Work through the live list of devices currently in violation.
# Configure compliance alert rules
Source: https://docs.getprimo.com/mdm/compliance/alert-rules
Choose which device statuses count as a violation so the alerts list reflects your organization's risk posture.
A compliance alert rule tells Primo: *"For this rule type, these statuses should trigger an alert."* Until you configure rules, the alerts list stays empty — Primo collects status data but does not flag anything.
## Open the rules panel
1. Go to **MDM > Compliance Alerts**.
2. Click **Manage rules** in the top-right of the page.
The page lists every rule type as its own section, with one toggle per possible status.
## Two kinds of rules
* **Global rules** — **Enrollment Status** and **Online Status**. These apply to every managed device and don't depend on any MDM control being configured. They're always available to configure.
* **MDM control rules** — every other rule type (encryption, OS update, password policy, firewall, Wi-Fi, antivirus, admin user management, and so on). These only become configurable once the matching MDM control exists.
If a rule's underlying MDM control isn't set up yet, the rule appears at the top of the page in a banner labelled **"X compliance alerts can't be set up yet"**, with a chip for each affected rule and a **Manage MDM controls** button that takes you to the MDM controls page. Configure the control there and the rule moves into the main list.
## Configure a rule
Scroll to the rule type you want to configure (for example, **Enrollment Status**, **Online Status**, **Recovery OS**, **Encryption**).
Each rule lists every possible status the device can report. Turn on the toggle next to each status you want to treat as a violation, and leave the rest off.
For example, on **Online Status**, many teams turn on **Offline 7+ days** but leave **Offline** off, because short check-in gaps are normal.
From the next device sync onward, any device reporting a flagged status appears on the **Compliance Alerts** page.
A rule with **no statuses toggled on** is effectively off — Primo records the status but never raises an alert.
## Reduce alert noise
If the alerts list is too noisy, return to **Manage rules** and turn off statuses that are too transient or expected. Common adjustments:
* **Online Status — Offline**: short check-in gaps are normal. Many teams alert only on **Offline 7+ days**.
* **Encryption — Missing recovery key**: escrow takes up to 24 hours and a restart after encryption turns on, so freshly encrypted devices trigger it transiently before it self-resolves.
* **OS Update — Grace period**: a Windows device that's late on an update but still inside its grace window. Leave off if you don't want admins to act until the grace period ends.
After you change a toggle, the next device sync recomputes the alert list and devices in those statuses drop off automatically.
## Rules waiting on an MDM control
Rules tied to MDM controls become configurable as soon as the underlying control is set up. Examples:
| Rule | Becomes available when |
| ------------------------------------------------------------------------------- | ------------------------------------------------- |
| ThreatDown / SentinelOne | The endpoint protection integration is connected |
| USB Blocking, App Blocking, Disable AirDrop, Screen Capture, Lock Profiles Pane | The matching MDM control exists |
| Admin Password Rotation | The admin password rotation control is configured |
| Entra SSO, Okta SSO | The corresponding identity control is configured |
Click **Manage MDM controls** in the banner at the top of the rules page to jump straight to the MDM controls list.
## Permissions
| Action | Permission |
| ---------- | ----------- |
| View rules | `MDM_READ` |
| Edit rules | `MDM_WRITE` |
## Next steps
* [Monitor compliance alerts](/mdm/compliance/alerts) — work through the list of devices currently in violation.
* [Compliance alert reference](/mdm/compliance/alert-reference) — what each status means before you decide whether it should alert.
# Monitor compliance alerts
Source: https://docs.getprimo.com/mdm/compliance/alerts
Triage devices that currently violate your compliance rules from a single live list.
The Compliance Alerts page lists every device that currently reports a status you've flagged as non-compliant. Use it as your daily triage queue.
## Open the alerts page
Go to **MDM > Compliance Alerts**.
The list updates automatically each time a device syncs. There is no scan to launch and no acknowledge action — alerts appear when a device drifts and disappear when it returns to a compliant state.
## Default columns
| Column | What it shows |
| ---------------- | ------------------------------------------------------------------------------------------------ |
| **Status** | The non-compliant status reported by the device (for example `NOT_ENCRYPTED`, `OFFLINE_7_DAYS`). |
| **Control name** | The MDM control or compliance rule that raised the alert. |
| **Type** | The rule category (encryption, OS update, antivirus, and so on). |
| **Device name** | The affected device. |
| **Date** | When Primo last evaluated the alert. The list is sorted most-recent first. |
## Filter and customize the view
The Alerts page uses Primo's table view system, so you can:
* Filter by **Device** or **Type**.
* Show or hide columns to keep only the ones you care about.
* Save a filtered view for later reuse.
The default view is named **All compliance alerts**. Sorting and grouping are not available on this table.
## Inspect a device
Click any row to open the device drawer. From there you can:
* Review the device's full status across every compliance rule.
* Jump to the related MDM control to verify the configuration.
* Run remediation actions exposed by the device drawer (push profile, lock, wipe, and so on — see [Manage your devices](/mdm/guides/wiping-devices)).
The device drawer also surfaces a quick **needs attention** indicator anywhere a device is shown in the dashboard, so you can spot issues without opening the alerts page.
## How alerts resolve
Alerts clear automatically. There is no manual acknowledge, snooze, or close. An alert disappears when:
* The device's status changes — encryption completes, the OS updates, the device comes back online, the missing profile is pushed.
* You remove that status from the rule's non-compliant list. See [Configure compliance alert rules](/mdm/compliance/alert-rules).
Re-evaluation runs on every device sync. There is no separate compliance scan to schedule.
## Permissions
Viewing alerts requires `MDM_READ`.
## Next steps
* [Compliance alert reference](/mdm/compliance/alert-reference) — what each status means, why it fires, and how to resolve it.
* [Configure compliance alert rules](/mdm/compliance/alert-rules) — adjust which statuses count as violations.
# Compliance overview
Source: https://docs.getprimo.com/mdm/compliance/overview
Continuously audit every managed device against your security and IT policies, surface deviations, and decide which device states should count as a violation.
Compliance answers two questions for IT and security teams:
* **Are my devices still in line with our policies?** For example, is the disk encrypted, is the operating system up to date, is the antivirus running, is the device still enrolled and online?
* **Which deviations should I be alerted about?** You decide which device statuses count as a violation. Anything you do not flag is ignored.
Every time a device syncs, Primo re-evaluates it against your compliance rules and updates the alert list automatically. There is no separate scan to launch and no alert to acknowledge by hand.
## Where compliance lives
Compliance is accessed from a single page in the dashboard:
* Go to **MDM > Compliance Alerts** to see the live list of devices currently violating your policies — your daily triage queue.
* From the same page, click **Manage rules** in the top-right to open the configuration panel where you choose which statuses (per rule type) count as a violation.
A device only appears in the alerts list if its current status matches a status you marked as non-compliant in **Manage rules**. Tune the rules, and the alert list updates on the next device sync.
## Key concepts
* **Rule type** — A category Primo audits. **Enrollment Status** and **Online Status** are global and apply to every device. Every other rule type (encryption, OS update, password policy, firewall, Wi-Fi, antivirus, admin user management, and so on) is tied to a specific MDM control and is only configurable once that control exists.
* **Status** — A rule-specific value such as **Encrypted**, **Not encrypted**, **Up to date**, **Offline 7+ days**. Each rule type has its own set of possible statuses.
* **Compliance alert rule** — A per-company configuration that lists which statuses, for a given rule type, should trigger an alert.
* **Compliance alert** — A device that currently reports a status flagged as non-compliant by one of your rules.
## How alerts work
Whenever a managed device checks in, Primo re-runs every compliance rule against it.
Each rule returns a status — for example **Encrypted** for the encryption rule, **Offline 7+ days** for the online rule.
If the status appears in the non-compliant list you configured for that rule, the device is flagged with an alert. Otherwise it is considered compliant.
When a device's status improves — encryption completes, the OS updates, the device comes back online — the alert clears on the next sync. There is no acknowledge or snooze action.
## Platform coverage
Compliance applies to every platform Primo manages: macOS, Windows, Linux, iOS, iPadOS, and Android. Each rule only returns meaningful results on platforms where the underlying control runs. For example, FileVault encryption applies only to macOS, BitLocker only to Windows, and SentinelOne to desktop platforms.
## Permissions
| Action | Permission |
| --------------------- | ----------- |
| View alerts and rules | `MDM_READ` |
| Edit alert rules | `MDM_WRITE` |
## Next steps
Choose which device statuses count as a violation.
Triage devices that drift from your policies.
Understand each alert status, its causes on macOS and Windows, and how to resolve it.
# Custom fields
Source: https://docs.getprimo.com/mdm/custom-fields
Define your own data attributes on devices to capture company-specific information, segment your fleet, power Device Group rules, and report on the data you need.
**Availability:** Custom fields are in beta and rolling out to accounts. If you don't see them yet, the feature isn't enabled for your organization. Custom fields apply to **Devices**, **Employees**, **Orders**, and **Accessories**.
## What are custom fields?
The dashboard includes a standard set of attributes on every device — model, operating system, serial number, assigned employee, and more. **Custom fields** let you add your own attributes to capture data that isn't tracked out of the box.
A custom field is a data attribute you define yourself — for example *Department*, *Asset Tag*, *Warranty Expiry*, or *Criticality*. Once created, it behaves like any other built-in attribute: you fill in a value on each record, then view, edit, and filter on it.
## Why use them — and who they're for
Custom fields address a few common needs:
* **Track data that isn't modeled out of the box.** Capture asset tags, purchase order numbers, warranty dates, and internal cost centers.
* **Segment your fleet.** Group and filter devices by your own categories (for example, *Department* or *Criticality*) instead of only by built-in attributes.
* **Power Device Group rules.** Use a custom field as a condition so the right devices automatically fall into the right [Device Group](/mdm/device-groups) and receive the right profiles and controls.
* **Report on your own data.** Surface your own attributes alongside standard device data.
They're built for:
* **IT admins** who need the fleet to reflect their organization's real structure and policies.
* **Asset managers** who track ownership, warranty, and lifecycle data per device.
## Key concepts
### Field
A **field** is the attribute you define. Each field has:
* A **name** (for example, *Department*).
* A **type** that determines what kind of value it holds (see below).
* An **applies to** scope that determines which records can hold a value for it.
### Field types
Choose a type when you create a field. The type can't be changed afterward, so pick the one that matches the data you're capturing.
| Type | Use this when… | Predefined options? |
| ---------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------- |
| **Text** | You need free-form text, like a note or an asset tag. | No |
| **Number** | You're capturing a numeric value, like a cost or a count. | No |
| **Date** | You're recording a date, like a warranty expiry. | No |
| **URL** | You're storing a link, like a vendor or ticket page. | No |
| **Checkbox (yes/no)** | The answer is yes or no, like *Under warranty*. | No |
| **Select (one choice)** | There's a fixed list and each device picks exactly one, like *Criticality: Low / Medium / High*. | Yes |
| **Multi-select (several choices)** | There's a fixed list and a device can have more than one, like *Installed peripherals*. | Yes |
**Options** are the predefined choices you set up for **Select** and **Multi-select** fields. The other types don't use options — the value is typed in directly.
### Applies to
**Applies to** defines which records a field can hold a value on. Custom fields apply to **Devices**, **Employees**, **Orders**, and **Accessories**.
You can **expand** what a field applies to later, but you can't **shrink** it. Once a field is available on a type of record, that availability stays — so set scope thoughtfully.
### Values
A **value** is the data entered for a field on a specific record — for example, the *Department* field with the value *Finance* on a particular laptop. Each record holds its own value for each field that applies to it.
## Use custom fields
### Create a field
Navigate to **Settings** > **Custom Fields** and review the existing fields in the table.
Click **Add field** and give the field a **name**.
Select a **type** (see [Field types](#field-types)).
If you chose **Select** or **Multi-select**, add the **options** users can pick from.
Set what the field **applies to** (Devices, Employees, Orders, or Accessories).
Save the field.
### Set values
Once a field exists, fill in its value on each record (device, employee, order, or accessory):
Open a device, employee, order, or accessory to bring up its detail panel (the drawer).
Find your custom field among the record's attributes.
Enter or pick the value inline and save.
### Edit a field
Refine a field after it's created. From **Settings** > **Custom Fields**, open the field to:
* **Rename the field.**
* **Add options** to a Select or Multi-select field.
* **Rename options.** Renaming an option does **not** lose data on devices already using it — those devices keep their value, now shown under the new label.
* **Widen what it applies to** (for example, extend it to a new record type once that's supported).
You can't change a field's **type**, and you can't **narrow** what it applies to.
### Filter and segment
Custom fields make your fleet easier to slice:
* **Filter the Devices list** by a custom field to find a subset of devices.
* **Target Device Groups** using a custom field as a rule, so matching devices are automatically included and receive the right profiles and controls.
**Current limit:** Filtering and Device Group targeting work with **Select**, **Multi-select**, and **Checkbox (yes/no)** fields. Text, Number, Date, and URL fields can't be used as filters yet.
### Delete a field
When you no longer need a field, delete it from **Settings** > **Custom Fields**. You can delete a field only when it has **no related entities** (see below).
#### Related entities
A **related entity** is anything that depends on a field. A field gains related entities when you use it in:
* a **saved (custom) view** that filters the Devices list by the field, or
* a **Device Group** that uses the field as a filter.
While a field has related entities, you **can't delete it** — the dashboard protects the views and groups that rely on it. A **Related entities** indicator shows exactly what's referencing the field. To delete it, first remove the field from those views and Device Group filters; once it has no related entities, the delete becomes available.
## What you can and can't do today
| You can | You can't (today) |
| ------------------------------------------------------------------------------ | ---------------------------------------------------------------------- |
| Create Text, Number, Date, URL, Checkbox, Select, and Multi-select fields | Change a field's type after it's created |
| Give two fields the same name (names don't have to be unique) | Delete a field while a saved view or Device Group filter still uses it |
| Delete a field that has no related entities | Delete a single option — remove the whole field instead if needed |
| Add and rename options on Select / Multi-select fields | Filter by Text, Date, Number, or URL fields yet |
| Filter and target Device Groups with Select, Multi-select, and Checkbox fields | Narrow what a field applies to |
| Widen what a field applies to | — |
| Apply fields to Devices, Employees, Orders, and Accessories | — |
| Edit values inline on a record | — |
## Availability and access
**Admins with access to Settings** manage custom fields under **Settings** > **Custom Fields**.
The feature is **in beta and rolling out** to accounts. If you don't see it in your Settings, the feature isn't enabled for your organization yet — contact your Primo representative.
# Device groups
Source: https://docs.getprimo.com/mdm/device-groups
Organize your fleet into device groups to apply MDM profiles and controls to specific sets of devices.
Use device groups to organize your fleet and apply different MDM profiles and controls to specific sets of devices. For example, create separate groups for your engineering team, a specific office, or a set of managed mobile devices.
## Create a device group
1. Go to **MDM > Device Groups**.
2. Click **New group**.
3. Name the group and optionally add a description.
4. Configure the filters that define which devices belong to the group.
5. Click **Save**.
## Filter devices
Device groups are dynamic — the filters you configure determine which devices belong to the group. You can filter by any available attribute, including:
* **Team**
* **Office**
* **Legal entity**
* **Tags**
* **Assignee**
* **Email provider groups** — the groups synced from your email provider, for example a **Google Workspace group**.
Combine filters to create precise targeting rules. The same filters are available in an MDM control's custom target.
Filtering on email provider groups requires Google Workspace or Microsoft Entra ID to be connected and set as your email provider. See [Connect your email provider](/saas/get-started/connect-email-provider).
## Assign a profile to a group
1. Open the device group.
2. Go to the **Profile** tab.
3. Select the MDM profile to apply.
4. Save the changes.
Devices in the group receive the associated controls within a few minutes.
# Bitdefender
Source: https://docs.getprimo.com/mdm/endpoint-protection/bitdefender
Deploy the Bitdefender GravityZone agent on macOS and Windows devices using Primo MDM.
Bitdefender GravityZone requires **manual setup** before deployment. Download the installation package from the GravityZone console and upload it to Primo. The package already includes your company configuration — no license key needs to be passed in the install script.
## How to deploy
1. In the GravityZone admin console, go to **Network > Packages**.
2. Select an existing deployment package or create a new one for each target platform.
3. Download the macOS (`.pkg`) and Windows (`.exe`) installers.
The downloaded packages already embed your company credentials and configuration — no additional activation step is needed.
For each installer (macOS and Windows):
1. In Primo, go to **MDM > Software > Add app > Custom app**.
2. Upload the installer file and click **Add software**.
No changes to the install script are needed — the default script handles installation correctly.
1. In FleetDM, go to **Policies > Add Policy** and use the query:
```sql theme={null}
SELECT 1 FROM apps WHERE bundle_identifier = 'com.bitdefender.EndpointSecurityforMac';
```
2. Name it **Bitdefender installed (macOS)** and save.
1. In FleetDM, go to **Policies > Add Policy** and use the query:
```sql theme={null}
SELECT 1 FROM programs WHERE name LIKE '%Bitdefender%';
```
2. Name it **Bitdefender installed (Windows)** and save.
Go to **Policies > Manage automations > Software** and assign each policy to its corresponding installer package. Fleet will automatically push the installer to any device that fails the policy check.
# CrowdStrike Falcon
Source: https://docs.getprimo.com/mdm/endpoint-protection/crowdstrike-falcon
Deploy the CrowdStrike Falcon agent on macOS and Windows devices.
CrowdStrike Falcon requires **manual setup** before deployment. Download the installer packages from the CrowdStrike console, upload them, and configure the install scripts with your `CustomerID`.
## How to deploy
1. In the CrowdStrike admin console, go to **Host setup and management > Deploy > Sensor downloads**.
2. Download the macOS (`.pkg`) and Windows (`.exe`) installers.
3. Copy your `CustomerID` (CID) — you'll need it in the next step.
For each installer (macOS and Windows):
1. Go to **MDM > Software > Add app > Custom app**.
2. Upload the installer file and click **Add software**.
In the Windows `.exe` package configuration, open **Show advanced options** and replace the scripts below. No script changes are needed for the macOS package.
Replace `CustomerID` with your actual CID:
```powershell theme={null}
$exeFilePath = "${env:INSTALLER_PATH}"
try {
$processOptions = @{
FilePath = "$exeFilePath"
ArgumentList = "/install /quiet /norestart CID=CustomerID"
PassThru = $true
Wait = $true
}
$process = Start-Process @processOptions
$exitCode = $process.ExitCode
Write-Host "Install exit code: $exitCode"
Exit $exitCode
} catch {
Write-Host "Error: $_"
Exit 1
}
```
```powershell theme={null}
try {
$regPaths = @(
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall",
"HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall"
)
$app = $regPaths |
ForEach-Object { Get-ChildItem $_ -ErrorAction SilentlyContinue } |
Get-ItemProperty |
Where-Object { $_.DisplayName -like "CrowdStrike Windows Sensor*" } |
Select-Object -First 1
if (-not $app) {
Write-Host "CrowdStrike Falcon not found, nothing to uninstall"
Exit 0
}
$processOptions = @{
FilePath = $app.UninstallString
ArgumentList = "/quiet /norestart"
PassThru = $true
Wait = $true
}
$process = Start-Process @processOptions
$exitCode = $process.ExitCode
Write-Host "Uninstall exit code: $exitCode"
Exit $exitCode
} catch {
Write-Host "Error: $_"
Exit 1
}
```
Click **Save changes**.
1. In FleetDM, go to **Policies > Add Policy**, name it **CrowdStrike installed (macOS)**, and use the query:
```sql theme={null}
SELECT 1 FROM apps WHERE bundle_identifier = 'com.crowdstrike.falcon';
```
2. Go to **Manage automations > Software** and link the policy to the macOS installer. Fleet will automatically push the installer to any device that fails the policy check.
1. In FleetDM, go to **Policies > Add Policy**, name it **CrowdStrike installed (Windows)**, and use the query:
```sql theme={null}
SELECT 1 FROM programs WHERE name = 'Falcon';
```
2. Go to **Manage automations > Software** and link the policy to the Windows installer. Fleet will automatically push the installer to any device that fails the policy check.
Go to **MDM > Controls**, open your macOS control, and upload the CrowdStrike system extension mobileconfig as a **Custom file**.
```xml theme={null}
PayloadContentPayloadDescriptionConfigures Privacy Preferences Policy Control settings for CrowdStrikePayloadDisplayNameFull Disk Access - CrowdstrikePayloadIdentifiercom.fleet.privacyPayloadOrganizationCrowdStrike Inc.PayloadTypecom.apple.TCC.configuration-profile-policyPayloadUUIDC7B25543-8A46-4782-B5F1-FABF2CC07934PayloadVersion1ServicesSystemPolicyAllFilesAllowedCodeRequirementidentifier "com.crowdstrike.falcon.Agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = X9E956P446CommentIdentifiercom.crowdstrike.falcon.AgentIdentifierTypebundleIDStaticCodeAllowedCodeRequirementidentifier "com.crowdstrike.falcon.App" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = X9E956P446CommentIdentifiercom.crowdstrike.falcon.AppIdentifierTypebundleIDStaticCodeNotificationSettingsAlertType1BundleIdentifiercom.crowdstrike.falcon.UserAgentCriticalAlertEnabledNotificationsEnabledShowInLockScreenShowInNotificationCenterPayloadDisplayNameNotificationsPayloadIdentifiercom.fleet.notificationsPayloadTypecom.apple.notificationsettingsPayloadUUIDF5E94A3F-6E76-4A28-AF32-068455731244PayloadVersion1PayloadDescriptionConfigures Service Management settings for CrowdStrike FalconPayloadDisplayNameService ManagementPayloadIdentifiercom.fleet.servicemanagementPayloadOrganizationCrowdStrike Inc.PayloadTypecom.apple.servicemanagementPayloadUUIDB2C3D4E5-F6G7-8901-2345-678901BCDEFGPayloadVersion1RulesRuleTypeBundleIdentifierRuleValuecom.crowdstrike.falcon.UserAgentRuleTypeTeamIdentifierRuleValueX9E956P446AllowedSystemExtensionsX9E956P446com.crowdstrike.falcon.AgentNonRemovableFromUISystemExtensionsX9E956P446com.crowdstrike.falcon.AgentPayloadDescriptionConfigures System Extensions Policy settings for CrowdStrike FalconPayloadDisplayNameSystem Extensions - CrowdstrikePayloadIdentifiercom.fleet.systemextensionsPayloadOrganizationCrowdStrike Inc.PayloadTypecom.apple.system-extension-policyPayloadUUID6527669C-0C1F-4B84-998F-33902DBFEB86PayloadVersion1FilterDataProviderBundleIdentifiercom.crowdstrike.falcon.AgentFilterDataProviderDesignatedRequirementidentifier "com.crowdstrike.falcon.Agent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] and certificate leaf[field.1.2.840.113635.100.6.1.13] and certificate leaf[subject.OU] = "X9E956P446"FilterGradeinspectorFilterPacketsFilterSocketsFilterTypePluginOrganizationCrowdStrike Inc.PayloadDisplayNameWeb Content FilterPayloadIdentifiercom.fleet.webfilterPayloadTypecom.apple.webcontent-filterPayloadUUIDE63C7607-408B-485F-BF2F-0900AAE6797FPayloadVersion1PluginBundleIDcom.crowdstrike.falcon.AppUserDefinedNameCrowdStrikePayloadDescriptionCrowdStrike Falcon - Full configuration (Full Disk Access, Notifications, Service Management, System Extensions, Web Filter)PayloadDisplayNameCrowdStrike Falcon ConfigurationPayloadEnabledPayloadIdentifiercom.primo.crowdstrikePayloadOrganizationPrimoPayloadRemovalDisallowedPayloadScopeSystemPayloadTypeConfigurationPayloadUUIDD269B6A4-2E8D-4EC1-B818-ADAE81B8CF0BPayloadVersion1
```
# SentinelOne
Source: https://docs.getprimo.com/mdm/endpoint-protection/sentinelone
Connect your SentinelOne instance to Primo and deploy the agent automatically on macOS, Windows, and Linux devices.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | ✅ | | |
**Deployment type: Automatic**
Once the integration is connected and the control is enabled, the agent is pushed to every targeted device via MDM. No manual installation and no user interaction are required.
## Prerequisites
* Primo MDM
* A SentinelOne license, purchased through Primo or already in place
Need a SentinelOne instance? Contact us or write to [support@getprimo.com](mailto:support@getprimo.com).
## Which setup applies to you
Three things change depending on where your SentinelOne instance comes from. Check which case you're in before you start.
| | Instance provided by Primo | Your own instance (BYO) |
| ---------------------- | ------------------------------------- | ---------------------------------------------------------- |
| Connection form | **Site ID** only | **SentinelOne URL** + **Site ID** + **Service User Token** |
| macOS system profile | Pushed automatically with the control | You upload it as a custom file |
| Fleet agent exclusions | Already set on the SentinelOne policy | You add them for macOS and Windows |
## Connect your SentinelOne instance
The **EDR - SentinelOne** cards stay greyed out in the control catalog until the integration is connected. Start here.
In Primo, go to **Settings > Integrations**, then open **SentinelOne** in the **EDR/MDR** section.
The step is titled **Create a service user for Primo and provide the API token**.
If the form displays the notice *"you probably don't need to fill site url nor service user token inputs, site ID is enough"*, your instance is hosted on Primo's SentinelOne tenant.
Fill in the **Site ID** only:
1. In SentinelOne, open **Policy & Settings > Sites**.
2. Click the site you want to connect and copy the Site ID.
Fill in all three fields:
* **SentinelOne URL** — `https://xxxxxxxxx.sentinelone.net`
* **Site ID** — in SentinelOne, open **Policy & Settings > Sites**, click the site you want to connect, and copy the Site ID.
* **Service User Token** — in SentinelOne, open **Policy & Settings > Service Users > New Service User**, scope the user to your site, assign the **Admin** role, then copy the token.
The token is displayed only once, at creation. Copy it before closing the SentinelOne dialog.
Two things confirm the connection:
* **SentinelOne** appears in the Primo main menu, next to **Fleet**, as a direct link to your console.
* The **EDR - SentinelOne** cards become selectable in the control catalog.
## Deploy SentinelOne to your fleet
Deployment runs through your MDM controls.
Go to **MDM > Controls > Add new control** and choose the platform.
Each card covers one platform and one architecture. Enable the one that matches your devices:
| Platform | Card | Covers |
| -------- | ----------------------------------- | ------------------------------------------- |
| macOS | **EDR - SentinelOne (x86/ARM64)** | Intel and Apple silicon |
| Windows | **EDR - SentinelOne (x86)** | Intel and AMD |
| Windows | **EDR - SentinelOne (ARM64)** | Windows on Arm |
| Linux | **EDR - SentinelOne (DEB / x86)** | Debian, Ubuntu, and derivatives |
| Linux | **EDR - SentinelOne (DEB / ARM64)** | Debian, Ubuntu, and derivatives |
| Linux | **EDR - SentinelOne (RPM / x86)** | RHEL, Fedora, CentOS, SUSE, and derivatives |
| Linux | **EDR - SentinelOne (RPM / ARM64)** | RHEL, Fedora, CentOS, SUSE, and derivatives |
Choose which devices the control applies to: all devices, specific device groups, or a custom target.
You don't need architecture-specific device groups. Each card only applies to the devices matching its platform and architecture, so mixed groups are handled correctly.
The agent is installed automatically on every device covered by the control.
## macOS system profile
The macOS agent needs a system profile granting it the system extension, Full Disk Access, notifications, and the network filter. Without it, the agent installs but stays partly inactive, and macOS prompts the user for approvals.
Nothing to do. The control pushes the profile along with the agent — you don't have to build or upload a `.mobileconfig`.
You supply the profile. Build it from the payloads published by SentinelOne for your agent version, then open your macOS control in Primo and upload it as a **Custom file** — same mechanics as [CrowdStrike Falcon](/mdm/endpoint-protection/crowdstrike-falcon).
## Exclude the Fleet agent from SentinelOne
SentinelOne can block, throttle, or quarantine the Fleet agent. When that happens, devices show up as **Missing agent** or offline in Primo while they are actually in use — see [Resolve enrollment issues](/mdm/guides/resolve-enrollment-issues).
On instances provided by Primo, these exclusions are already set on the SentinelOne policy. This section applies to your own instance (BYO), where you have to add them for macOS and Windows.
Add the paths below as **Path** exclusions in your SentinelOne console, scoped to the site connected to Primo, with **Include subfolders** enabled and the mode set to **Interoperability**.
| Platform | Path (default install location) | Component |
| -------- | ------------------------------------------------------ | ------------------- |
| macOS | `/opt/orbit/bin/orbit/orbit` | Fleet agent (orbit) |
| macOS | `/opt/orbit/bin/osqueryd/osqueryd` | osquery daemon |
| macOS | `/opt/orbit/bin/desktop/Fleet Desktop.app` | Fleet Desktop |
| Windows | `C:\Program Files\Orbit\bin\orbit\orbit.exe` | Fleet agent (orbit) |
| Windows | `C:\Program Files\Orbit\bin\osqueryd\osqueryd.exe` | osquery daemon |
| Windows | `C:\Program Files\Orbit\bin\desktop\fleet-desktop.exe` | Fleet Desktop |
Linux agents use the same `/opt/orbit` paths as macOS.
Excluding the parent folder — `/opt/orbit/` on macOS and Linux, `C:\Program Files\Orbit\` on Windows — covers the binaries through agent upgrades, which rewrite the executables underneath.
## Modify or remove the control
Disable the card from the control settings. Disabling stops enforcement on new devices but does not uninstall the agent from devices where it is already running.
## Uninstall the agent from a device
Anti-tampering blocks any removal that isn't authorized from the console: an end user who runs the uninstaller only triggers an uninstall request for you to approve or deny.
1. Get the passphrase: in the SentinelOne console, go to **Agent management > Endpoints**, open the endpoint, then click **Actions > Agent Actions > Show Passphrase**.
2. Uninstall from the console (**Actions > Uninstall**), or from the CLI with local admin rights:
```bash theme={null}
sudo sentinelctl unprotect --passphrase "passphrase"
sudo sentinelctl uninstall --local
```
Run as `root` — `sudo` alone is not enough. Without `--unquarantine`, quarantined files are deleted instead of restored.
```bash theme={null}
/opt/sentinelone/bin/sentinelctl control uninstall --passphrase "passphrase" --unquarantine
```
Use the package downloaded from the console, not the one in `Program Files`. Reboot afterwards.
```powershell theme={null}
msiexec.exe /quiet /norestart /x Agent_version.msi UNINSTALL_KEY="passphrase"
```
**No passphrase?** An agent that never connected to a console takes an empty string. For a leftover agent from a decommissioned console, retrieve its passphrase from that console if you still have access. Otherwise, on macOS, boot the device into Recovery Mode and follow SentinelOne's uninstall procedure from there. On Windows and Linux, go through SentinelOne Support rather than a script found on a forum.
## Renew the Service User Token
SentinelOne service user tokens expire — the lifetime is set when the service user is created. Once the token expires, the integration stops syncing and device protection statuses go stale in Primo.
Create a new service user in **Policy & Settings > Service Users**, then paste the new token in **Settings > Integrations > SentinelOne**. Note the expiry date somewhere you'll see it before it lands.
## Migrate to another SentinelOne console
To move your endpoints from one SentinelOne console to another, update the install scripts first, then migrate the endpoints.
An endpoint can only migrate if it is online, has no unresolved threats, and is not running a full disk scan. Offline endpoints stay pending until they check in again. You need Global or Account-level permissions on the source console — on a console provided by a partner, that level may sit with the partner rather than with you.
Prepare the destination site first: SentinelOne policies can't be exported, so they have to be rebuilt there. For a full tenant migration, SentinelOne Support can carry the configuration over for you.
1. Open your Fleet instance at `https://.mdm.getprimo.com`.
2. Go to the **Software** tab and search for `Sentinel` (SentinelOne, Sentinel Agent, and similar).
3. For each package: click **Edit**, open **Show advanced options**, and replace the old site token with the new one in the install script.
Devices that install the agent from now on will register against the new console.
In your SentinelOne console, select the endpoints to migrate, then go to **Actions > Endpoint actions > Migrate endpoints**. Enter the new site token and confirm.
The token must belong to a site on the **destination** console. A token taken from the source console fails silently — no error, and the endpoints stay where they are.
Migration is not destructive: an agent that can't reach the new console within a few minutes stays registered on the original one.
Track progress with the **Console Migration Status** filter under **More filters** — `N/A`, `Pending`, or `Migrated`. The activity log of the source console also records the destination URL for each agent that moved.
Migrated endpoints stay listed in the source console, greyed out. They don't leave on their own: decommission them once the destination console shows them active, or shorten the decommission window so offline agents are swept out automatically. Until you do, the same devices are counted on both consoles — worth settling with your provider before you start.
Before you lose access to the source console, export the passphrases of the endpoints that did **not** migrate — those are the ones you may have to handle by hand. Migrated agents get a new UUID and a new passphrase from the destination console, so the old ones are useless. Running the first batch before exporting keeps the list short.
Go back to **Settings > Integrations > SentinelOne** and update the Site ID, URL, and Service User Token to match the new console.
## Unsupported platforms
If your platform is not listed above, you can still install SentinelOne manually: download the installer from the SentinelOne console and deploy it with Fleet as a custom app.
# ThreatDown
Source: https://docs.getprimo.com/mdm/endpoint-protection/threatdown
Deploy ThreatDown (by Malwarebytes) automatically to protect your device fleet against security threats.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | ✅ | | |
ThreatDown deployment through Primo requires a license purchased through Primo. Contact us to get started.
## How to set it up
Choose which devices to apply the control to: all devices, specific device groups, or a custom target.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
Once the control is deployed, Primo automatically installs the ThreatDown agent on targeted devices via MDM. No user interaction or manual installation is required.
# Android
Source: https://docs.getprimo.com/mdm/get-started/initial-setup-android
Learn how to set up MDM for your Android devices below.
## Version support
| Android version | Supported |
| --------------- | --------- |
| `13+` | ✅ |
| `12` and below | ❌ |
## How MDM works
Primo uses Fleet as its MDM agent for Android. The agent is installed via a lightweight package and communicates with Primo to report device state, enforce policies, and run scripts.
## Initial setup
Android MDM requires connecting a Managed Google Play account to enable app deployment and policy enforcement on enrolled devices.
Open the **MDM** section and select **Android**.
Follow the prompts to link your organization's Managed Google Play account. This registers your organization with Android Enterprise and authorizes Primo to manage Android devices on your behalf.
Once connected, Android MDM is active. Devices can now be enrolled and apps can be deployed from the Play Store.
## Enrollment modes
Android supports two enrollment modes. Both are available on every enrollment surface (MDM settings, employee enrollment stepper, and invite emails) — pick the mode that matches how the device is owned and staged.
### Personal (work profile)
Use this on **personal devices** an employee already owns. Company apps and data live in a separate work profile; personal apps, photos, and accounts stay private and outside Primo's visibility.
Employees enroll themselves:
1. Open the enrollment link on the Android device (or scan the QR code shown next to the link).
2. Tap **Enroll** and follow the on-screen steps to create the work profile.
### Company-owned (fully managed)
Use this on **new or factory-reset company devices**. The entire device is managed by Primo — there is no separate personal profile.
Fully-managed enrollment is an IT-staging flow, not a self-service one. It requires access to both a second screen and the device during setup:
1. On a computer or tablet, open the fully-managed enrollment link. Fleet displays a provisioning QR code. Keep the page open.
2. Power on the Android device on its welcome screen. If the device has already been set up, factory-reset it first.
3. Tap the welcome screen 6 times to open the QR code scanner, then scan the provisioning QR code from step 1.
The device provisions itself as fully managed and appears in the dashboard once enrollment completes.
Fleet generates the provisioning QR code on demand, and it expires roughly one hour after the link is opened. Open the link right before scanning it, not in advance.
## Next steps
* [Deploying Android apps](/mdm/policies/google-play-store)
# Linux
Source: https://docs.getprimo.com/mdm/get-started/initial-setup-linux
Learn how to set up MDM for your Linux devices below.
## Distribution support
| Distribution | Minimum version |
| ------------------------------- | ---------------------------- |
| Ubuntu | `20.04+` |
| Debian | `11+` |
| Fedora | `38+` |
| CentOS | `7.1+` |
| Red Hat Enterprise Linux (RHEL) | `7+` |
| Amazon Linux | `2+` |
| openSUSE | `15.6+` |
| Arch Linux | ✅ |
| Omarchy | ✅ |
| Alpine | ❌ (APK format not supported) |
## How MDM works
Primo uses Fleet as its MDM agent for Linux. The agent is installed via a lightweight package and communicates with Primo to report device state, enforce policies, and run scripts.
## Initial setup
Linux requires no additional configuration. MDM activates as soon as you create your Primo account and works out of the box.
# Windows
Source: https://docs.getprimo.com/mdm/get-started/initial-setup-windows
Learn how to set up MDM for your Windows devices below.
## Edition support
| Edition | Supported |
| ------------- | --------- |
| Pro | ✅ |
| Enterprise | ✅ |
| Education | ✅ |
| Home / Family | ❌ |
Windows Home does not support MDM enrollment. See [Platform support](/mdm/get-started/supported-platforms#windows) for details on Home limitations.
## How MDM works
Primo uses Fleet as its MDM agent for Windows. The agent is installed via a lightweight `.msi` installer and communicates with Primo to report device state, enforce policies, and run scripts.
## Initial setup
No additional certificates or portal configuration are required for Windows. MDM is activated as soon as your Primo account is created and works out of the box.
You also have the option to automatically migrate enrolled hosts from another MDM to Primo — no manual re-enrollment required.
## Next steps
* [Zero Touch deployment for Windows](/mdm/zero-touch/zero-touch-windows)
# Apple
Source: https://docs.getprimo.com/mdm/get-started/set-up-apn-certificate
Learn how to set up MDM for your Apple devices below.
## Introduction to APNs
The Apple Push Notification Service (APNs) is an essential component of MDM for Apple devices. It enables Primo to communicate remotely, securely, and instantly with the devices.
To use this service, Primo requires an APN certificate which is tied to your organisation and has to be renewed every 12 months.
Once configured, APNs allows Primo to:
* **Push remote configurations** (encryption, firewall, updates, password settings, sleep settings, app installation, WiFi deployment, etc.)
* **Send real-time commands**, even when the device is locked or in sleep mode
* **Ensure silent communication**, without user interaction
## Import your APN certificate
Go to **MDM** > **Apple** and download the CSR (Certificate Signing Request) file.
Open [identity.apple.com/pushcert](https://identity.apple.com/pushcert).
Click **Create a certificate** and upload the CSR file downloaded from Primo.
We recommend using a shared Apple ID — the certificate is tied to the Apple ID used to create it and must be renewed every 12 months using that same account.
Once generated, download the `.pem` certificate file from Apple.
Go back to **MDM** > **Apple** and upload the certificate. Your MDM instance is now fully configured and operational.
## Renew your APN certificate
The certificate remains valid for 12 months. Primo will notify you by email and display a banner in the cockpit when renewal is due. Repeat the steps above using **the same Apple ID** used to create the original certificate.
## Next steps
* [Zero Touch deployment for Mac](/mdm/zero-touch/zero-touch-macs)
* [Deploy App Store apps (VPP)](/mdm/policies/app-store-apps)
# Platform support
Source: https://docs.getprimo.com/mdm/get-started/supported-platforms
Primo supports macOS, Windows, Linux, iOS, Android, and ChromeOS — enroll any device, apply policies, and manage your entire fleet from a single platform.
Enroll devices, enforce policies, and manage your fleet from one place — regardless of whether your company runs Mac, Windows, Linux, mobile, or a mix of everything.
## Platform support
| | **macOS** | **Windows** | **Linux** | **iOS, iPadOS** | **Android** | **ChromeOS** |
| ---------------------- | --------- | ---------------------- | ----------------------------------------- | -------------------- | ----------------- | ------------------ |
| **Minimum version** | `14+` | `10+` (Pro/Enterprise) | Ubuntu `20.04+` [²](#linux-distributions) | `17+` | `13+` | `112+` |
| **Enroll and monitor** | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| **Encrypt disks** | ✅ | ✅ | ✅ [³](#linux-notes) | N/A [⁴](#ios-ipados) | N/A [⁵](#android) | ✅ |
| **Remote lock & wipe** | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ |
| **Apply controls** | ✅ | ✅ | ❌ | ✅ | ✅ | N/A [⁶](#chromeos) |
| **Install software** | ✅ | ✅ [¹](#windows) | ✅ | ✅ | ✅ | N/A [⁶](#chromeos) |
| **Run scripts** | ✅ | ✅ [¹](#windows) | ✅ | N/A | N/A | ❌ |
## Notes
### Windows
#### Windows Home
Due to platform limitations, Windows Home devices do not support features like disk encryption management, remote locking, and remote wiping.
#### ARM architecture
Primo supports software installation on ARM hosts, but with limitations. The maintained app catalog mostly contains 64-bit x86 versions of applications, and deploying them on ARM hosts can fail or produce unintended results.
### Linux
You can centralize reporting on encryption status across your Linux fleet and escrow recovery keys to retain access if a device is locked. However, the dashboard does not manage disk encryption on Linux — configure encryption at OS setup.
#### Supported distributions
| Distribution | Supported versions |
| ------------------------------- | ---------------------------- |
| Ubuntu | `20.04+` |
| Debian | `11+` |
| CentOS | `7.1+` |
| Fedora | `38+` |
| Amazon Linux | `2+` |
| Red Hat Enterprise Linux (RHEL) | `7+` |
| openSUSE | `15.6+` |
| Arch Linux | ✅ |
| Omarchy | ✅ |
| Alpine | ❌ (APK format not supported) |
### iOS, iPadOS
iOS and iPadOS devices are **natively encrypted** by Apple — no configuration required. Disk encryption cannot be toggled or managed via MDM. Scripts and OSQuery are not available (platform limitation).
### Android
Android devices are **natively encrypted** — encryption is enforced by the OS and cannot be managed via MDM. Scripts and OSQuery are not available (platform limitation).
### ChromeOS
Primo can enroll ChromeOS devices for monitoring. However, **controls, software installation, and policy enforcement** are managed through your **Google Admin console**, not directly via Primo. For details on how to set this up, contact support.
# Activation Lock bypass code escrow
Source: https://docs.getprimo.com/mdm/guides/activation-lock-bypass
Rules for ensuring Activation Lock bypass codes are escrowed via MDM so devices can be recovered after a wipe or reassignment.
Activation Lock prevents unauthorized use of an Apple device after a factory reset. For company-owned devices enrolled in MDM, Primo escrows the bypass code automatically. You can then unlock a device after a wipe without the employee's Apple ID.
On Mac, Activation Lock only applies to devices with Apple Silicon or the Apple T2 Security Chip. Older Intel Macs without a T2 chip are not affected ([Apple Deployment Guide](https://support.apple.com/guide/deployment/depf4ab94ef1/web)).
## OS support
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | | | ✅ | |
## The two types of Activation Lock
Apple distinguishes two ways Activation Lock can be enabled on an organization-owned device ([Apple Deployment Guide](https://support.apple.com/guide/deployment/depf4ab94ef1/web)):
* **Organization-linked** — requires the device to be in Apple Business Manager (ABM) or Apple School Manager. The MDM contacts Apple's servers directly to lock and unlock the device, using its own server-generated bypass code. Nothing depends on the user, on Find My, or on the state of the device.
* **User-linked** — the user locks the device to their personal Apple Account by enabling **Find My**. This is the type covered by the escrow rules and scenarios below.
If both types are attempted on the same device, the first Activation Lock event that enables the feature takes precedence.
## Rules for escrowing bypass codes
All of the following conditions must apply for Primo to escrow a bypass code:
1. **The device must be supervised via MDM** — unsupervised devices cannot escrow bypass codes.
2. **You must enroll the device before Activation Lock is enabled** — if a user activates Find My before MDM enrollment, Primo cannot retrieve the bypass code.
3. **The device must be company-owned** — personally-owned (BYOD) devices are not eligible for bypass code escrow.
4. **The MDM profile must install at the system level** — user-approved enrollment (without DEP/ABM) does not reliably escrow bypass codes.
If you enroll a device in MDM after the user has already signed in with an Apple ID and enabled Find My, **Primo cannot escrow the bypass code**. The only recovery option is the user's Apple ID credentials.
## Scenarios and caveats
Whether a bypass code is usable depends on the device's supervision state and the order in which device management and Activation Lock were enabled. The same **iCloud Lock** field in the dashboard can show a value that is reliable in one scenario and a false positive in another.
### Key terms
* **Supervision** — per [Apple](https://support.apple.com/en-gb/guide/deployment/dep1d89f0bff/web), supervision "denotes that the device is owned by the organisation, which provides additional control over its configuration and restrictions." A device is supervised when enrolled through Automated Device Enrollment (ADE), zero-touch deployment, or Apple Business Manager (ABM). On macOS 11 and later, Macs enrolled via account-driven or profile-based Device Enrollment are also supervised. Standard user enrollment does not grant supervision.
* **Activation Lock** — Apple's protection that ties a device to an Apple ID after a wipe. It triggers when a user enables **Find My** on the device.
* **Bypass code** — a device-based code that removes Activation Lock without the user's Apple ID. The code only exists if Primo escrowed it.
* **Escrow** — device management stores the bypass code at the moment Activation Lock activates. Escrow is not retroactive.
### The three scenarios
On macOS 11 and later, most enrolled Macs are supervised (Scenario 1), even without zero-touch. Scenarios 2 and 3 apply to devices that remain unsupervised — for example, older macOS versions or pure user enrollment.
| Scenario | Supervision | Order of events | Bypass code |
| ----------------------------------- | ---------------------------- | ----------------------------------- | -------------- |
| **1. Supervised** | Supervised (ZTD / ADE / ABM) | Enrolled via zero-touch | ✅ Reliable |
| **2. Unsupervised, enrolled first** | Unsupervised | MDM enrolled → then Find My enabled | ✅ Escrowed |
| **3. Unsupervised, Find My first** | Unsupervised | Find My enabled → then MDM enrolled | ❌ Not escrowed |
**Scenario 1 — Supervised device.** Activation Lock is not a blocker. Device management sends an `ActivationLockBypassCodeCommand` directly to the device, regardless of when the user enabled Find My. The bypass code is reliable.
**Scenario 2 — Unsupervised, MDM enrolled before Find My.** You enrolled the device manually (unsupervised), but device management was already in place when the user enabled Find My. Primo escrowed the bypass code at that moment, and you can use it.
**Scenario 3 — Unsupervised, Find My before MDM.** The user enabled Find My before enrolling in device management. Activation Lock was already active, so Primo could not escrow a bypass code. Any code shown in the dashboard is a **false positive** — entering it on the Activation Lock screen returns `Your Apple Account or password is incorrect`. The only recovery option is the user's Apple ID credentials.
Apple provides no way to confirm whether an escrowed bypass code is a valid device-based code. On unsupervised devices, users can also toggle Find My off and on without re-escrowing a new code. Treat the **iCloud Lock** value on unsupervised devices as unverified until you confirm the device's enrollment history.
## Check bypass code availability
* ✅ *Enabled* — the bypass code is available and escrowed.
* ❌ *Missing bypass code* — Primo did not back up a code, and you need the original Apple ID.
Audit devices showing **Missing bypass code** regularly to identify devices that may be unrecoverable after a wipe. Re-enroll these devices via ABM when possible.
## On macOS
Retrieve the bypass code from the device record, then start the Mac and wait for the Activation Lock screen. Click **Recovery Assistant** in the menu bar and select **Activate with MDM key**, then enter the bypass code ([Apple Deployment Guide](https://support.apple.com/guide/deployment/depf4ab94ef1/web)).
The bypass code is case-sensitive and single-use per device.
## On iOS / iPadOS
For iOS and iPadOS devices, retrieve the bypass code from the device record. On the Activation Lock screen during device setup after a wipe, enter the bypass code in the **password** field and leave the username field empty ([Apple Deployment Guide](https://support.apple.com/guide/deployment/depf4ab94ef1/web)).
The bypass code is case-sensitive and single-use per device.
On iPhone and iPad, you can only retrieve the device-generated bypass code during the **15 days** following first supervision of the device (or until an MDM explicitly fetches and clears it). If Primo did not escrow the code within that window, it is gone for good.
## Recover a Mac stuck on the Activate Mac screen
If a Mac was wiped while Activation Lock was still active and no valid bypass code exists (Scenario 3), it stays locked on the **Activate Mac** screen. Do not keep retrying the bypass code — it returns `Your Apple Account or password is incorrect` because the code was never escrowed.
Work through these options in order.
### Option 1 — Disable Activation Lock from Apple Business Manager
If the Mac was added to ABM **before** Activation Lock was enabled, and has not been released from the organization, a user with device management privileges can disable Activation Lock directly from ABM — for both organization-linked and user-linked locks. The device does not need to be assigned to an MDM server ([Apple Deployment Guide](https://support.apple.com/guide/deployment/depf4ab94ef1/web)).
For an **organization-linked** lock that the MDM fails to remove, there is one more fallback: on the Activation Lock screen, sign in with the ABM account that created the MDM server token linking Primo to ABM.
### Option 2 — Ask the former user
If the previous user is reachable, they can release the lock themselves:
* by signing in with their Apple ID directly on the Activation Lock screen, or
* by removing the device from their account: go to [icloud.com/find](https://www.icloud.com/find), select the device, then choose **Remove This Device** ([Apple Support](https://support.apple.com/108934)). This also works from any of their other Apple devices.
This is usually the fastest path — try it before contacting Apple.
### Option 3 — Apple Support with proof of ownership
If the former user is unreachable, Apple can remove Activation Lock when the organization proves it owns the device. Gather these before contacting Apple:
* the original purchase invoice in the company's name, showing the device serial number
* the device serial number (visible on the Activation Lock screen or on the chassis)
* company details and the requester's identity
Submit the request through [Apple's Activation Lock support page](https://al-support.apple.com/), or through your AppleCare for Business or Enterprise agreement if you have one ([Apple Support: How to remove Activation Lock](https://support.apple.com/108934)). Verification typically takes several days. Apple rejects requests with an incomplete invoice or a missing serial number.
This situation is almost always avoidable: sign the user out of iCloud before wiping any unsupervised Mac. See [Wiping devices](/mdm/guides/wiping-devices).
***
## Related articles
* [Wiping devices](/mdm/guides/wiping-devices)
* [Locking devices](/mdm/guides/locking-devices)
* [Migrate using Apple Business](/mdm/rollout/migrating-macs-using-abm)
* [Apple Deployment Guide — Activation Lock for Apple devices](https://support.apple.com/guide/deployment/depf4ab94ef1/web)
* [Apple Support — How to remove Activation Lock](https://support.apple.com/108934)
# Clear passcode
Source: https://docs.getprimo.com/mdm/guides/clear-passcode
Remotely remove the lock screen passcode on a managed Android device so an employee who forgot their PIN, pattern, or password can regain access and set a new one.
Clear passcode removes the lock screen credential on a managed Android device without erasing any data. Use it when an employee forgets their PIN, pattern, or password and cannot unlock their device. The employee can then unlock the device immediately and set a new passcode the next time they lock the screen.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ❌ | ❌ | ❌ | ❌ | ✅ |
Clear passcode works on both **company-owned** and **personally-owned (BYOD)** Android devices enrolled with Primo.
## When to use it
* An employee has forgotten their device passcode and cannot unlock their phone or tablet.
* You need to unlock a returned device before wiping or reassigning it.
* A device is locked and you want to hand it back to the employee without factory-resetting it.
For other lockout scenarios, see [Locking devices](/mdm/guides/locking-devices) or [Wiping devices](/mdm/guides/wiping-devices).
## Clear the passcode
Find the Android device in the **Devices** list and open its details.
Primo only shows this action for Android devices with MDM on.
Primo sends the command immediately and cannot cancel it.
Primo removes the lock screen credential the next time the device syncs. The employee can then unlock the device and set a new passcode when prompted.
Clear passcode is triggered immediately and cannot be cancelled. Only run it when the employee is ready to receive their device unlocked.
## Related articles
* [Locking devices](/mdm/guides/locking-devices)
* [Wiping devices](/mdm/guides/wiping-devices)
* [Android initial setup](/mdm/get-started/initial-setup-android)
# Find the right program name for Automatic Install
Source: https://docs.getprimo.com/mdm/guides/find-program-name
How to identify the exact software name to use in your auto-install detection query on Windows and Linux.
When you enable Automatic Install on a `.exe`, `.ps1`, `.deb`, `.rpm`, `.sh`, or `.tar.gz` custom package, Primo pre-fills a best-effort osquery using the software name you provided. Fleet's auto-install semantics require this query to **return at least one row when the software is installed** — otherwise the agent will keep re-installing the package on every check.
Edit the `LIKE '%...%'` value in the pre-filled query so it matches the **exact name the operating system reports** for the installed program.
## Windows (`.exe`, `.ps1`)
Pre-filled query:
```sql theme={null}
SELECT 1 FROM programs WHERE name LIKE '%%'
```
How to find the exact name:
* **Fleet host details** → installed programs list
* **Apps & features** in Windows Settings
* PowerShell: `Get-Package | Where-Object Name -Like '**'`
Example — installer is `FalconSensor_Windows.exe`, Windows reports the program as `CrowdStrike Windows Sensor`:
```sql theme={null}
SELECT 1 FROM programs WHERE name LIKE '%CrowdStrike Windows Sensor%'
```
## Linux Debian / Ubuntu (`.deb`)
Pre-filled query:
```sql theme={null}
SELECT 1 FROM deb_packages WHERE name LIKE '%%'
```
How to find the exact name:
* `dpkg -l | grep ` — the first column shows the package name
* Match the **package** name (e.g. `google-chrome-stable`), not the human-readable display name
## Linux RPM (`.rpm`)
Pre-filled query:
```sql theme={null}
SELECT 1 FROM rpm_packages WHERE name LIKE '%%'
```
How to find the exact name:
* `rpm -qa | grep `
* Use the bare package name (without version / arch suffix)
## Linux scripts / archives (`.sh`, `.tar.gz`)
For installer scripts and archives, the installed artifact is whatever the script drops on disk. Inspect the script (or its README) to determine:
* Whether it registers a package in `deb_packages` / `rpm_packages` — if yes, query that table
* Otherwise, check whether a known binary or directory is created — use `file` or `osquery_info` to query for it
## Common mistakes
* Using the **installer filename** (`Setup.exe`) instead of the **registered program name** (`MyApp`) — Fleet will never detect it as installed and will re-install on every run
* Forgetting the wildcards (`'%name%'`) — exact-match queries miss version suffixes
* Using a name that matches multiple unrelated programs — tighten the `LIKE` pattern with more characters or use `=` for exact match
## Verify before saving
In the software card, after editing the query, target a small device group first and confirm the install behaves as expected before rolling it out fleet-wide.
# Locking devices
Source: https://docs.getprimo.com/mdm/guides/locking-devices
Remotely lock a managed Mac, Windows, Linux, iOS, iPadOS, or Android device from the dashboard to prevent unauthorized access when a device is lost or an employee is offboarded.
Remote lock immediately prevents access to a managed device without erasing its data. Use it when a device is temporarily lost or misplaced, or as a first step before deciding whether to wipe.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | ✅ | ✅ | ✅ |
## How to lock a device
The device will lock at the screen level — the employee will be prompted for their credentials (or a recovery PIN on macOS) before regaining access.
On macOS, the screen displays a PIN code.
**To unlock the device:**
* Enter the **6-digit PIN** displayed in the dashboard at the time the lock was triggered.
* Once unlocked, the device returns to normal operation — no data is lost.
On Windows, remote lock triggers a screen lock equivalent to pressing **Windows + L**. The device is immediately locked and requires the user's Windows credentials to unlock.
**To unlock the device:**
* An admin needs to enter their Windows password or PIN.
On Linux, remote lock sends a script via the FleetDM agent that locks the screen session. The exact behavior depends on the desktop environment in use.
On iOS and iPadOS, locking a device enables **Lost Mode**. The device displays a custom message and phone number on the lock screen, and its location is tracked.
Lost Mode is available on supervised devices with MDM turned on.
**To unlock the device:**
* Go to **Devices**, open the device details page, and click **Actions > Unlock**.
* The device exits Lost Mode and returns to normal operation.
On Android, remote lock immediately locks the screen. The employee is prompted for their existing passcode, PIN, or pattern before regaining access. No data is erased.
Remote lock works on both **company-owned** and **personally-owned (BYOD)** Android devices enrolled with Primo.
**To unlock the device:**
* The employee enters their existing device passcode, PIN, or pattern.
* If the employee has forgotten their passcode, use [Clear passcode](/mdm/guides/clear-passcode) to remove it so they can set a new one.
## Related articles
* [Wiping devices](/mdm/guides/wiping-devices)
* [Clear passcode](/mdm/guides/clear-passcode)
* [Activation Lock bypass](/mdm/guides/activation-lock-bypass)
# Wiping devices
Source: https://docs.getprimo.com/mdm/guides/wiping-devices
Remotely erase a managed Mac, Windows, Linux, iOS, iPadOS, or Android device from the Primo cockpit. This is critical when a device is lost, stolen, or being reassigned. Understand the wipe options available per platform and when to use each.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ---------------------- |
| ✅ | ✅ | ✅ | ✅ | ✅ (company-owned only) |
## Wipe a device
1. Go to **Devices** and open the device details page.
2. Click **Actions > Wipe**.
3. Select the wipe mode (where applicable).
4. Confirm the action.
The device receives a **Wipe pending** status. Once acknowledged, it updates to **Wiped**.
On macOS, a remote wipe erases all user data and reinstalls macOS from recovery. The Mac returns to factory defaults.
* If the device has Activation Lock enabled, disable it first or confirm a valid bypass code is escrowed — see [Activation Lock bypass](/mdm/guides/activation-lock-bypass).
* For zero-touch deployment devices, the Mac automatically re-enrolls on first boot.
* Otherwise, the employee must re-enroll manually.
**Before wiping: release Activation Lock**
If Activation Lock is still active when the wipe completes, the Mac reboots to the **Activate Mac** screen and asks for the previous user's Apple ID. On supervised devices the escrowed bypass code unlocks it, but on unsupervised (manually enrolled) devices the code can be a false positive — see [the three scenarios](/mdm/guides/activation-lock-bypass#the-three-scenarios).
While the device is still accessible and unlocked:
1. Open **System Settings** and select the user's Apple Account.
2. **Sign out of iCloud** — this disables Find My Mac. The user's Apple ID password is required.
3. Confirm **Find My Mac** is disabled and no Apple Account session remains.
4. Back up any data you need — the wipe is irreversible.
5. Launch the wipe.
6. After the device reboots, confirm it reaches Setup Assistant without showing the Activate Mac screen.
On an unsupervised Mac, never wipe before signing the user out of iCloud. If Find My was enabled before MDM enrollment, no valid bypass code exists and the device will lock on the Activate Mac screen. Recovery then requires the former user or Apple Support — see [Recover a Mac stuck on the Activate Mac screen](/mdm/guides/activation-lock-bypass#recover-a-mac-stuck-on-the-activate-mac-screen).
Primo offers two wipe modes for Windows: **Standard wipe** and **Hard wipe**. Each maps to a different Microsoft MDM command and has different behavior.
| | **Standard wipe** | **Hard wipe** |
| ----------------------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Microsoft command** | [`doWipe`](https://learn.microsoft.com/en-us/windows/client-management/mdm/remotewipe-csp#dowipe) | [`doWipeProtected`](https://learn.microsoft.com/en-us/windows/client-management/mdm/remotewipe-csp#dowipeprotected) |
| **What it does** | Factory reset equivalent to **Reset this PC > Remove everything** | Fully cleans the internal drive and keeps retrying until complete |
| **Can be interrupted** | Yes — power-cycling can stop the process | No — resumes automatically after any interruption |
| **If interrupted** | Attempts roll-back; if roll-back fails, device may be unusable | Retries on next boot until complete |
| **Risk of unbootable device** | Low | Higher |
| **Best for** | Device reassignment, routine refresh | Lost or stolen devices, confirmed security incidents |
**When to use each mode**
| Scenario | Recommended mode |
| --------------------------------------------- | ------------------------------------------------------------------------- |
| Device lost or stolen | **Hard wipe** — ensures data is erased even if the process is interrupted |
| Employee offboarding with device reassignment | **Standard wipe** — sufficient when you have physical access |
| Device compromised by malware | **Hard wipe** — guarantees a full clean even if malware interferes |
| Routine device refresh | **Standard wipe** — lower risk, easier recovery if something goes wrong |
**Limitations**
* **Windows Home is not supported** — remote wipe requires Windows Pro, Enterprise, or Education. See [platform support](/mdm/get-started/supported-platforms).
* **Wipe is irreversible** — you cannot cancel it once initiated and acknowledged.
* **BitLocker recovery key** — the previous key is no longer valid after a wipe. Ensure it is backed up beforehand.
On Linux, a remote wipe erases device data via a script the Fleet agent executes. Behavior depends on the distribution, disk layout, and encryption setup. You may need to reinstall the OS from scratch.
On Android, a remote wipe factory-resets the device and removes all user data, apps, and accounts. The device returns to its out-of-the-box state.
**Requirements**
* Wipe is only available on **company-owned** Android devices (enrolled through the automatic zero-touch flow).
* Personally-owned (BYOD) Android devices cannot be wiped from Primo — to remove company data from a BYOD device, use [Disenroll](/mdm/rollout/device-assignment) instead.
**After the wipe**
* The device is unenrolled from Primo.
* The device reboots to the Android setup screen and can be re-enrolled or handed to a new employee.
***
## Related articles
* [Locking devices](/mdm/guides/locking-devices)
* [Clear passcode](/mdm/guides/clear-passcode)
* [Activation Lock bypass](/mdm/guides/activation-lock-bypass)
* [Set up Zero Touch for Mac](/mdm/zero-touch/zero-touch-macs)
# Vanta
Source: https://docs.getprimo.com/mdm/integrations/vanta
Send your Primo admin accounts and your macOS and Windows device inventory to Vanta every hour, and know exactly which fields leave Primo.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | | | |
**Data flow: one-way**
Primo pushes to the Vanta API. Vanta sends nothing back, so no Vanta data appears in the dashboard.
This article covers what Primo sends, how the sync behaves, and how to connect or reconnect the integration. What Vanta does with the data once it arrives is documented by Vanta. For Primo's own device compliance monitoring, which is unrelated to this integration, see [Compliance overview](/mdm/compliance/overview).
## Prerequisites
* A Primo MDM plan. The Identity & Access Management module is not required.
* A Vanta administrator account. Administrator level is required to authorize the integration.
## Connect Vanta
Go to **Settings > Integrations**, then open **Vanta** in the **Compliance** section.
You are redirected to Vanta. Authorize the connection there.
Vanta then asks you to grant access. Confirm, and you are returned to the integration page, which now shows **Disconnect**.
## What Primo sends
Primo sends three types of resources.
* **Primo admin accounts** — administrators only. Employees who are not administrators are not included.
* **macOS devices**
* **Windows devices**
### Admin account fields
* **Display name** and **full name**
* **Email address**
* **Creation date**
* **Authentication method** — **SSO** or **password**
* **Multi-factor authentication (MFA)** — whether MFA is enabled, and the methods in use: **OTP**, **SMS**, or disabled
* **Permission level**
### Device fields
macOS and Windows devices are sent with the same fields, except where the Notes column says otherwise.
| Field | Notes |
| ---------------------------------- | ------------------------------------------------------------------- |
| Device name | |
| Link to the device record in Primo | |
| Serial number | |
| Hardware identifier | |
| Operating system name and version | |
| Last data collection date | |
| Last enrollment date | |
| Owner email address | Omitted when the device has no owner in Primo |
| MDM management state | Computed field, see below |
| Automatic updates | Computed field, see below |
| Disk encryption | **FileVault** on macOS, disk encryption on Windows |
| Anti-malware protection | macOS only. Whether a malware protection control targets the device |
| Screen lock policy | Password requirement and delay. Computed field, see below |
| Minimum password length | Computed field, see below |
| Installed software | Applications on macOS, programs on Windows |
| Browser extensions | |
### How the computed fields are derived
Some fields come from the MDM controls targeting the device rather than from the device itself. A control that does not target the device has no effect on the values sent for it.
* **MDM management state** — Sent as managed when the device is enrolled and active in the MDM: automatic enrollment, company-owned device enrollment, or manual enrollment. Every other state — enrollment disabled, pending, or unknown — is sent as unmanaged. This is unrelated to whether the device is company-owned.
* **Automatic updates** — Sent as enabled when an OS update control carrying an update deadline targets the device. This follows the control targeting each device, not a company-wide setting. See [Enforce OS updates](/mdm/policies/enforce-minimum-os-version).
* **Screen lock policy** — Derived from the password policy MDM controls on macOS and Windows. Without the [Password and screenlock](/mdm/policies/password-policy) control configured, no policy is sent.
* **Minimum password length** — Taken from the password policy control targeting the device. When no password policy control targets it, the field is left out of the push rather than filled with a default.
## What Primo does not send
The integration covers admin accounts and devices. Everything below stays in Primo.
* Employees who are not Primo administrators. The integration carries no personnel directory and no onboarding, mobility, or offboarding events.
* SaaS application accounts and access rights.
* Endpoint protection data. [SentinelOne](/mdm/endpoint-protection/sentinelone) and [ThreatDown](/mdm/endpoint-protection/threatdown) data is present in Primo but is not sent. The device fields above cover whether a malware protection control targets a macOS device, not the data those tools collect.
* Firewall status.
* Linux devices, and iPhone, iPad, and Android devices. The Vanta API accepts macOS and Windows only.
* Devices absent from the agent inventory. Without the agent installed, a device is never sent.
## How the sync runs
* Primo pushes once an hour.
* Every push contains the complete current state of your fleet, not the changes since the last push.
* Because each push is a full state, an interruption fixes itself. If Vanta stops accepting data for a while, the next hourly push resends the whole fleet and brings Vanta up to date. There is nothing to reconnect and nothing for you to do.
There is no manual resync action, and the dashboard does not show a last-sync date.
## Disconnect or reconnect
The integration page shows one action, depending on the state of the connection.
* **Disconnect** — shown while the connection is active. Disconnecting stops the hourly push.
* **Reconnect** — shown once the connection has been interrupted. Reconnecting takes you back through the same two Vanta prompts and restores the authorization.
## Troubleshooting
**Vanta stopped receiving data, but the fleet is managed in Primo**
* Open **Settings > Integrations > Vanta**. If the page offers **Reconnect**, the authorization was interrupted.
* Disconnect, then reconnect. That restores the authorization.
**A device is missing in Vanta**
* Check its platform. Linux, iPhone, iPad, and Android devices are never sent.
* Check that the agent is installed. Devices absent from the agent inventory are not sent.
* Wait for the next hourly push before looking further. Each push resends the whole fleet.
**A device has no owner in Vanta**
* Assign an owner to the device in Primo. The owner email address is omitted from the push when the device has no owner.
# Network whitelisting
Source: https://docs.getprimo.com/mdm/network-requirements
Which Primo MDM and Apple endpoints must be reachable for enrollment, policy delivery, and push notifications to work when devices are behind a firewall or proxy.
Primo MDM communicates with managed devices over HTTPS. When devices sit behind a corporate firewall or proxy, the endpoints below must be reachable outbound for enrollment, policy delivery, and push notifications to function.
## Primo MDM server
Every Primo account has a dedicated MDM server URL:
```
[company slug].mdm.getprimo.com
```
Managed devices connect to this host for enrollment and to receive MDM commands. Allow outbound **TCP 443** to this hostname.
## Platform-specific endpoints
Apple MDM relies on the Apple Push Notification service (APNs) to wake devices when a command is pending. Without APNs access, devices do not receive MDM commands in real time.
| Host | Ports | Purpose |
| ---------------------------- | --------- | -------------------------------------------- |
| `*.push.apple.com` | 443, 2197 | Push notifications (APNs) |
| `albert.apple.com` | 443 | Device activation |
| `deviceenrollment.apple.com` | 443 | Automated Device Enrollment (via ABM or ASM) |
| `mdmenrollment.apple.com` | 443 | MDM enrollment |
| `iprofiles.apple.com` | 443 | Configuration profile delivery |
Older networks that block non-standard HTTPS ports also require TCP 5223 outbound to `*.push.apple.com`. If you are unsure, allow it.
For a complete and up-to-date list of Apple hosts and ports, see [Use Apple products on enterprise networks](https://support.apple.com/en-gb/101555).
The Primo agent communicates outbound on port 443 exclusively to your Primo MDM server. No additional endpoints are required.
The Primo agent communicates outbound on port 443 exclusively to your Primo MDM server. No additional endpoints are required.
The Primo agent communicates outbound on port 443 exclusively to your Primo MDM server. No additional endpoints are required.
## Summary
| Endpoint | Port | Required for |
| --------------------------------- | --------- | ---------------------------- |
| `[company slug].mdm.getprimo.com` | 443 | All platforms |
| `*.push.apple.com` | 443, 2197 | Apple MDM push notifications |
| `albert.apple.com` | 443 | Apple device activation |
| `deviceenrollment.apple.com` | 443 | Apple automated enrollment |
| `mdmenrollment.apple.com` | 443 | Apple MDM enrollment |
| `iprofiles.apple.com` | 443 | Apple profile delivery |
All connections are **outbound HTTPS** from managed devices. No inbound firewall rules are required on the device side.
## Advanced: specific routes
If you use a reverse proxy or firewall with path-level rules and prefer not to allowlist an entire domain, use the route-level allowlist below.
### Devices roaming outside VPN or intranet
To manage devices that travel outside your VPN or intranet, expose only the osquery endpoints:
```
/api/osquery/*
/api/v1/osquery/*
```
| Route | Purpose |
| ----------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| `/mdm/apple/scep` | Devices obtain a SCEP certificate |
| `/mdm/apple/mdm` | Devices communicate using the MDM protocol |
| `/api/mdm/apple/enroll` | Devices fetch an enrollment profile (automated enrollment) |
| `/api/*/fleet/device/*` | End users access their device page (manual enrollment profile, disk encryption key rotation) |
| `/mdm/sso`, `/api/*/fleet/mdm/sso`, `/mdm/sso/callback`, `/api/*/fleet/mdm/sso/callback`, `/assets/*` | End user IdP authentication during out-of-the-box setup (if required) |
| `/api/*/fleet/mdm/setup/eula/*` | End user EULA agreement during out-of-the-box setup (if required) |
| `/api/*/fleet/mdm/bootstrap` | Bootstrap package installation during out-of-the-box setup (if applicable) |
`/mdm/apple/scep` and `/mdm/apple/mdm` sit outside the `/api` path because they implement non-RESTful Apple MDM protocols, not standard API endpoints.
| Route | Purpose |
| ------------------------------- | ----------------------------------------------------------------------------- |
| `/api/mdm/microsoft/management` | Devices receive MDM commands and profiles |
| `/api/mdm/microsoft/discovery` | Devices discover MDM server information |
| `/api/mdm/microsoft/policy` | Enrollment policies for identity certificate issuance |
| `/api/mdm/microsoft/enroll` | WS-Trust X.509v3 token enrollment (MS-WSTEP) |
| `/api/mdm/microsoft/tos` | Terms of Service agreement during out-of-the-box setup (automated enrollment) |
| `/api/mdm/microsoft/auth` | End user authentication during out-of-the-box setup (automated enrollment) |
| Route | Purpose |
| --------------------------------------------- | ---------------------------------------------------------------------- |
| `/enroll` | End users access the enrollment page to download an enrollment profile |
| `/api/*/fleet/enrollment_profiles/ota` | Devices download an enrollment profile |
| `/api/*/fleet/software/titles/*/in_house_app` | In-house app (`.ipa`) deployment |
| Route | Purpose |
| -------------------------------------------------- | ---------------------------------------------------------------------------------- |
| `/enroll` | End users access the enrollment page |
| `/api/*/fleet/android_enterprise/enrollment_token` | Primo receives the Android Management API enrollment token |
| `/api/*/fleet/android_enterprise/pubsub` | Primo receives enrollment and status notifications from the Android Management API |
| `/api/fleetd/*` | Certificate deployment for Wi-Fi/VPN connectivity |
### SCEP proxy
If you use Primo as a SCEP proxy:
```
/mdm/scep/proxy/*
```
### mTLS
The `/api/*/fleet/*` routes used by the Primo agent support mutual TLS (mTLS) using the certificate provided during agent packaging.
The `/mdm/apple/mdm` and `/api/mdm/apple/enroll` endpoints support mTLS using the SCEP certificate issued by the Primo server.
The following endpoints do **not** use mTLS:
```
/mdm/apple/scep
/api/mdm/microsoft/discovery
/api/mdm/microsoft/auth
/api/mdm/microsoft/policy
/api/mdm/microsoft/enroll
/api/mdm/microsoft/management
/api/mdm/microsoft/tos
```
For macOS and Windows, the MDM client sends the client certificate in a request header. The Primo server then verifies this certificate independently.
# Admin password rotation
Source: https://docs.getprimo.com/mdm/policies/admin-password-rotation
Automatically rotate and securely back up local administrator account passwords on a scheduled basis to reduce the risk of credential reuse and unauthorized access.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | | | |
## How to set it up
Choose how often passwords are rotated (e.g. every 30, 60, or 90 days).
Enter the username of the local administrator account to rotate.
Save and apply to the relevant device group.
## Modify or remove the control
To update the rotation interval or target account, disable the control and re-enable it with new settings.
# AirDrop restriction
Source: https://docs.getprimo.com/mdm/policies/airdrop-restriction
Control AirDrop discoverability on macOS devices to prevent unauthorized file sharing.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | | | | |
## How to set it up
Choose the discoverability level from the dropdown:
* **Off — AirDrop disabled**: prevents the device from being discovered via AirDrop and disables file transfers through it.
Choose which devices to apply the control to: all macOS devices, specific device groups, or a custom target.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
Primo pushes an MDM restriction that sets AirDrop discoverability to Off on targeted devices. Users cannot enable AirDrop or make their device discoverable through it.
# App blocking
Source: https://docs.getprimo.com/mdm/policies/app-blocking
Control which applications can run on macOS devices using Monitor, Lockdown, or Standalone enforcement modes. Powered by Santa, an open-source macOS security agent developed by Google.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | | | | |
## Set up app blocking
* **Monitor**: executions of binaries not covered by a rule are allowed. Use this mode to block specific applications while letting everything else run.
* **Lockdown**: executions of binaries not covered by a rule are blocked. Use this mode to permit only an explicit list of approved applications.
* **Standalone**: executions of binaries not covered by a rule trigger an authorization dialog, letting the user approve the application themselves.
Add applications by their **bundle identifier** (e.g. `com.spotify.client`) or **executable name**.
To find an application's bundle identifier on macOS, run the following command in Terminal:
`osascript -e 'id of app "AppName"'`
Save and apply the control to the relevant device group.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
This control is powered by [Santa](https://github.com/google/santa), an open-source macOS security agent developed by Google. Santa intercepts every binary execution request and evaluates it against the configured rules before allowing or denying it.
In **Monitor** mode, Santa terminates only binaries matching a block rule. In **Lockdown** mode, Santa terminates any binary without an explicit allow rule. In **Standalone** mode, binaries without a rule prompt the user for authorization before launching.
When Santa blocks an application, it terminates the process and shows a system notification explaining that the application is not permitted. The control enforces rules continuously — if a user installs an unapproved application after you apply the control, Santa evaluates it the next time the user attempts to launch it.
## Troubleshooting
**An allowed application is being blocked**
* Double-check the bundle identifier for typos — identifiers are case-sensitive.
* Confirm the control is targeting the correct device group.
* Re-check the enforcement mode: in **Lockdown**, applications without an allow rule are blocked by default. Either switch to **Monitor**, or add the application to your allow rules.
**A blocked application is still running**
* The policy is applied at launch time. If the application was already open when the policy was deployed, restart the device or ask the user to quit and reopen the application.
# App Store apps
Source: https://docs.getprimo.com/mdm/policies/app-store-apps
Deploy Apple App Store apps to macOS and iOS/iPadOS devices using Apple's Volume Purchase Program (VPP).
App Store Apps are deployed through Apple's Volume Purchase Program (VPP), which lets you purchase app licenses in bulk and push them to devices without requiring individual Apple IDs from employees.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | | | ✅ | |
## When to use
* The app is available on the Mac App Store or iOS App Store
* You want Apple to manage installer updates automatically
* You need to deploy apps to supervised iOS/iPadOS devices
## Prerequisites
* An **Apple Business Manager (ABM)** account
* VPP connected to the dashboard
## Connect Apple Volume Purchase Program (VPP)
1. In ABM, go to **Sites** and create a site if you don't have one.
2. Generate a **VPP token** from that site and download it.
Never connect the same VPP token to two MDMs simultaneously. This causes conflicts and may remove apps from devices. If you're migrating from another MDM, see [Migrate VPP from another MDM](#migrate-vpp-from-another-mdm) below.
1. Go to **MDM > Software > Add app > App Store (VPP)**.
2. Select the **"No Team"** scope.
3. Upload the VPP token file.
Before deploying an app, ensure you have enough licenses:
1. In ABM, go to **Apps and Books**.
2. Search for the app and purchase the required number of licenses.
3. Assign the licenses to the site linked to your VPP token.
Licenses are automatically reassigned when a device is unenrolled.
* A content token is valid for one year after it is created.
* It becomes invalid if the password of the Managed Apple Account that created it is changed.
* **Recommendation:** create a dedicated Managed Apple Account with a custom role limited to the "Assign licenses for Apps and Books" permission, so token validity does not depend on an individual's password changes or departure.
## Migrate VPP from another MDM
Follow this order — Apple requires the content token to be removed from your previous MDM before it's uploaded anywhere else.
This is done by your previous provider or in their console. Apple requires the token to be removed there before it's uploaded to Primo.
Go to **Settings > Payments & Billing > Apps and Books > Download**.
Follow the [Import the token](#connect-apple-volume-purchase-program-vpp) step above.
Some apps may need to be manually reassigned to devices after the new token is active.
Apps already installed on devices stay usable for up to 30 days after the old token is removed, or until the app developer performs a receipt check. Don't spread the migration over a longer window.
## Available options
* **Install automatically** — the app is silently pushed to all targeted devices (macOS, iOS, iPadOS).
* **Self-service** — the app appears in the Self-Service portal for employees to install on demand (macOS, iOS, iPadOS).
* **Install during Zero Touch** — the app is pre-installed during device provisioning (macOS only).
**How employees open the Self-Service portal depends on the platform.**
* **macOS** — from the **Fleet Desktop** icon in the menu bar.
* **iOS / iPadOS** — from the portal's web URL. Add it to the Home Screen with the **Web Clips** control and its **Add the Self-Service web clip** option.
On iOS and iPadOS the portal is also the only way to restart a VPP install after the employee dismisses the App Store confirmation prompt — reopen the app in the portal and tap **Retry**.
## How to add
1. Go to **MDM > Software** and click **Add app**.
2. Select **App Store (VPP)** and choose the platform (macOS or iOS/iPadOS).
3. Browse or search for the app.
4. Configure deployment options.
5. Click **Add software**.
## App patching
| | |
| ------------------------------- | --------------------------------------------------------------------------------- |
| **Keep installer updated** | ✅ The installer is always sourced directly from the App Store — always up to date |
| **Automatically patch devices** | ✅ Devices running an older version are updated automatically |
# Automatic app and OS updates
Source: https://docs.getprimo.com/mdm/policies/automatic-updates
Configure automatic update settings for macOS devices to keep apps and the operating system up to date in the background.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | | | | |
## How to set it up
Toggle on the update behaviors you want to enforce:
* **Download newly available updates in the background**
* **Automatically install macOS updates**
* **Automatically install App Store app updates**
* **Automatically install security updates**
Choose which devices to apply the control to: all macOS devices, specific device groups, or a custom target.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
Primo pushes an MDM configuration payload that controls macOS Software Update behavior. Enabled toggles override the user's local Software Update preferences — users cannot disable the configured update behaviors.
# Change a local session password
Source: https://docs.getprimo.com/mdm/policies/change-local-password
To update a local session password from the Primo cockpit, ensure you are an administrator, that the device is enrolled and online, then navigate to the Users tab, modify the session password, and monitor the change status in the Logs tab for successful sign-in with the new credentials.
This article explains how to update a local session password from the Primo cockpit. This action allows administrators to remotely update or reset user passwords on managed devices.
## Prerequisites
* You are an administrator of your company space.
* The device is enrolled in the MDM.
* The device is **Online** (powered on and connected to the internet).
* An administrator session exists on the device.
## Update the password from Primo
1. In the device details page, go to the **Users** tab.
2. Click **Action** next to the session you want to modify.
3. Enter the new temporary password and save it.
You can monitor the password change status in the **Logs** tab.
## Use the new password on the device
You or the user can sign in with the new credentials at the next session login.
The local session password is now updated.
## Reset the Windows Hello PIN
If the Windows Hello PIN code does not work and the user cannot use their password, you can reset the PIN by running a PowerShell script that deletes the Windows Hello PIN folder (NGC) and restarts the related service:
* This script stops the NgcCtnrSvc service.
* Takes ownership and sets permissions on the NGC folder.
* Removes NGC folder contents to force PIN recreation.
* Restarts the NgcCtnrSvc service.
The user will be required to create a new PIN after the reset.
**Important:**
* Import and run the script with Fleet
* Ideally, execute the script when the user is logged off.
* Logs for this operation are saved at `C:\ProgramData\MDM\Logs\Reset-WindowsHelloPIN.log`.
*Refer to the [Password Policy](/mdm/policies/password-policy) and [Resolve a login issue related to a password](/mdm/guides/resolve-login-issue) articles for additional guidance on password and PIN management.*
# Custom file
Source: https://docs.getprimo.com/mdm/policies/custom-file
Import a custom configuration profile to apply settings not covered by Primo's built-in controls, with support for native profile formats on macOS, iOS/iPadOS, Windows, and Android.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | | ✅ | ✅ |
## How to set it up
Upload your configuration file. The file is delivered to devices via MDM in the same way as any other control.
Primo does not validate the contents of custom files. Ensure your configuration is correct before deploying — an invalid or conflicting profile may cause unexpected device behavior.
Give the control a descriptive name so it is easy to identify later.
Save and apply the control to the relevant device group.
## Modify or remove the control
To change the configuration, re-upload the config file with updated settings. Disabling the control stops enforcement but does not remove existing configurations from devices.
## How it works
Each platform accepts its native configuration format:
| Platform | Format | Description |
| ------------ | -------------------------- | ----------------------------------------------- |
| macOS | `.mobileconfig` or `.json` | Apple Configuration Profile (XML-based) or JSON |
| iOS / iPadOS | `.mobileconfig` | Apple Configuration Profile (XML-based) |
| Windows | `.xml` | Windows MDM custom policy (SyncML format) |
| Android | `.json` | Android Enterprise managed configuration |
macOS configuration profiles (`.mobileconfig`) are XML files, signed or unsigned, delivered as MDM payloads. macOS also supports `.json` for certain configuration payloads.
To create profiles, the recommended tools are:
* **[iMazing Profile Editor](https://imazing.com/profile-editor)** — free, purpose-built for creating and editing `.mobileconfig` files
* **Apple Configurator** — available on the Mac App Store
Common use cases include custom certificate payloads, VPN profiles, and per-app VPN configurations.
iOS and iPadOS use the same `.mobileconfig` format as macOS.
Windows custom files use the SyncML format, which maps to Windows MDM CSPs (Configuration Service Providers). This allows you to configure any policy exposed by the Windows MDM stack that is not covered by Primo's built-in controls.
Android custom files use JSON to deliver managed configurations to Android Enterprise devices. This is typically used to configure enterprise applications that support managed app configuration.
## Troubleshooting
**The file upload fails**
* Confirm the file matches the expected format for the selected OS.
* Check that the file is not corrupted or empty.
* macOS profiles must use valid XML — validate the file with `plutil -lint profile.mobileconfig`.
# Custom software
Source: https://docs.getprimo.com/mdm/policies/custom-software
Deploy your own installer packages — internal tools, enterprise builds, or any app not in the Fleet catalog.
Custom software lets you upload and deploy your own installer packages to managed devices. Use it for internal tools, proprietary software, or any app not available in the Fleet-Maintained catalog.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | ✅ | ✅ | |
## When to use
* The app is not available in the Fleet catalog
* You need to deploy an internal or proprietary tool
* You have a specific version requirement
## Supported formats
| Platform | Formats |
| ------------ | -------------------------------- |
| macOS | `.pkg` |
| Windows | `.msi`, `.exe`, `.ps1` |
| Linux | `.deb`, `.rpm`, `.sh`, `.tar.gz` |
| iOS / iPadOS | `.ipa` |
## Available options
* **Install automatically** — the app is silently pushed to all targeted devices. Toggle on or off at any time; toggling off deletes the underlying Fleet auto-install policy and reverts the software to manual install.
**`.pkg`, `.msi`** — Primo auto-generates the detection policy. No extra configuration required.
**`.exe`, `.ps1`, `.deb`, `.rpm`, `.sh`, `.tar.gz`** — Fleet cannot auto-generate the detection policy for these installers. When you enable Automatic Install, Primo pre-fills a best-effort osquery based on the software name. **Review and edit the query before saving.** See [How to find the right program name](../guides/find-program-name) for help.
**`.ipa` (iOS / iPadOS)** — automatic install is not supported.
* **Self-service** — the app appears in the Self-Service portal for employees to install on demand
* **Install during Zero Touch** — the app is pre-installed during device provisioning
## How to add
1. Go to **MDM > Software** and click **Add app**.
2. Select **Custom app**.
3. Upload your installer file.
4. Configure deployment options.
5. Click **Add software**.
## App patching
| | |
| ------------------------------- | ---------------------------------------------------------------------------------------- |
| **Keep installer updated** | ❌ Not available — you must upload a new package manually when a new version is available |
| **Automatically patch devices** | ❌ Not available — devices are not updated automatically when you upload a new version |
To update an app on devices, upload a new installer and re-deploy.
# Device naming
Source: https://docs.getprimo.com/mdm/policies/device-naming
Use AI to automatically generate and enforce consistent device names across your macOS, Windows, and Linux fleet based on employee and device attributes.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | ✅ | | |
## How to set it up
Write a prompt that defines the automated naming structure for your devices. Be specific for optimal results — for example, describe the format using device type, serial number, or employee name.
Include instructions for edge cases such as devices without a serial number or unassigned devices. Allowed characters: letters, numbers, and hyphens.
Keep names under 15 characters if you need compatibility with older network systems that enforce NetBIOS name length limits — this is especially relevant for Windows devices.
Use the preview to verify the output before deploying.
Choose which devices to apply the control to: all devices, specific device groups, or a custom target.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
When a device is enrolled or its assigned employee changes, Primo evaluates the naming prompt and pushes the generated hostname to the device via MDM. The update happens silently in the background — no user interaction or restart is required.
Names are re-evaluated automatically whenever the underlying attributes change, keeping your inventory current.
# Disk encryption
Source: https://docs.getprimo.com/mdm/policies/disk-encryption
Enforce full-disk encryption across your fleet and automatically escrow recovery keys so IT can always regain access without relying on employee credentials.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ------------- | ------------- | ----- | ------------ | ------- |
| ✅ (FileVault) | ✅ (BitLocker) | | | |
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing encryption from devices.
## How it works
* **FileVault** manages encryption.
* Enabling the Disk Encryption control turns on FileVault.
* Encryption takes effect after the next restart.
* Primo escrows the recovery key within 24 hours after that restart.
* **BitLocker** manages encryption.
* Enabling the Disk Encryption control turns on BitLocker.
* No restart is required.
* Primo stores the key as soon as encryption activates.
Configure disk encryption **at OS installation**, before MDM enrollment. Linux has no native mechanism to encrypt a disk after install — adding encryption later requires a full reinstall. **Fleet Desktop** (the agent running on the device) handles recovery key escrow, not the Primo interface.
**Flow:**
1. The employee encrypts their disk with **LUKS** during OS installation.
2. Once enrolled, Fleet Desktop shows a banner prompting the employee to escrow their recovery key.
3. The employee clicks **Create key** and enters their existing LUKS passphrase.
4. Fleet generates and stores a new recovery passphrase server-side.
For more details, see the FleetDM documentation:
* [Linux disk encryption — end-user flow](https://fleetdm.com/guides/linux-disk-encryption-end-user)
* [Enforce disk encryption with Fleet](https://fleetdm.com/guides/enforce-disk-encryption)
# Enforce OS updates
Source: https://docs.getprimo.com/mdm/policies/enforce-minimum-os-version
Require devices to run a minimum operating system version to ensure security patches and app compatibility are maintained across your fleet.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | | ✅ | |
## How to set it up
Select when devices should be forced to update relative to when the OS update becomes available:
* **1 month after** the OS update is available
* **1 week after** the OS update is available
* **1 day after** the OS update is available
Choose the time of day at which the update is enforced on macOS devices. This uses **local device time**.
Configure the number of days employees have to update before the device automatically restarts to apply the update.
Choose which devices to apply the control to: all devices, specific device groups, or a custom target.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
When a minimum version is enforced, employees are prompted to update their OS according to the deadline and notification behavior described below.
The deadline applies from the **update availability date**, not the date the policy was configured. If employees are already on an older version when the policy is enabled, they will be prompted to update immediately.
**macOS 14 and later**
Employees see a native macOS notification (DDM) once per day. They can choose to update ahead of the deadline or schedule it for that night.
* **24 hours before the deadline** — notification appears hourly and ignores Do Not Disturb
* **1 hour before the deadline** — notification appears every 30 minutes, then every 10 minutes
* **If the device was off when the deadline passed** — the update is scheduled for 1 hour after it turns on
For devices using Automated Device Enrollment (ADE) that are below the minimum version, the update is required before device setup and enrollment can proceed.
***
**macOS 13 and earlier**
Employees are prompted via **Nudge**.
| | **> 1 day before deadline** | **\< 1 day before deadline** | **Past deadline** |
| --------------------------- | --------------------------- | ---------------------------- | -------------------- |
| Nudge window frequency | Once a day at 8pm GMT | Once every 2 hours | Immediately on login |
| End user can defer | ✅ | ✅ | ❌ |
| Nudge window is dismissible | ✅ | ✅ | ❌ |
Employees are prompted via the native Windows update dialog.
| | **Before deadline** | **Past deadline** |
| ------------------------------------ | ------------------- | ----------------- |
| End user can defer automatic restart | ✅ | ❌ |
If an employee was away when the deadline passed, they are given the configured grace period before the device automatically restarts.
## Troubleshooting
### **Low disk space**
If updates are failing due to low disk space, an administrator may need to intervene. None of the platforms automatically manage disk space to install updates.
* **macOS 14+** — the employee sees a system notification and a warning in System Settings. They must free up space to stop the prompts.
* **macOS 13 and earlier** — the Nudge window appears and directs employees to System Preferences, where the download will fail. The Nudge window cannot be dismissed after the deadline until the update is installed.
* **Windows** — the employee is notified that the update failed and must free up space to proceed.
# Firewall
Source: https://docs.getprimo.com/mdm/policies/firewall
Enable the built-in operating system firewall on macOS and Windows devices to block unauthorized inbound network connections.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | | | |
## How to set it up
No additional configuration is required. Choose which devices to apply the control to: all devices, specific device groups, or a custom target.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
Primo enables the built-in firewall on targeted devices via MDM. The firewall blocks unsolicited inbound connections while allowing outbound traffic. No additional configuration is required — enabling the control is sufficient to protect devices on both macOS and Windows.
# Fleet-maintained software
Source: https://docs.getprimo.com/mdm/policies/fleet-maintained-software
Deploy popular apps from a curated, pre-packaged catalog maintained by Fleet — no installer management required.
Fleet-Maintained Apps (FMA) are a curated library of popular software (Slack, Zoom, Chrome, and more) packaged and kept up to date by Fleet. Use them when you want to deploy widely-used apps without managing installers yourself.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | | | |
## When to use
* The app you need is available in the Fleet catalog
* You want Primo to handle installer updates automatically
* You want automatic patching on devices without manual effort
## Available options
When adding a Fleet-Maintained App, you can configure:
* **Install automatically** — the app is silently pushed to all targeted devices
* **Self-service** — the app appears in the Self-Service portal for employees to install on demand
* **Install during Zero Touch** — the app is pre-installed during device provisioning before the employee first uses the device
Enabling **Install during Zero Touch** increases provisioning time. Reserve it for apps that must be present before first use.
## How to add
1. Go to **MDM > Software** and click **Add app**.
2. Select **Fleet-Maintained App**.
3. Choose the app from the catalog.
4. Configure deployment options and patching toggles.
5. Click **Add software**.
## App patching
| | |
| ------------------------------- | ------------------------------------------------------------------------------------- |
| **Keep installer updated** | Primo checks daily for a newer version and updates the source installer automatically |
| **Automatically patch devices** | Devices where an older version is installed are updated automatically |
Both toggles are available and recommended for Fleet-Maintained Apps.
# Generate settings via AI
Source: https://docs.getprimo.com/mdm/policies/generate-settings-via-ai
Use Primo's AI engine to create tailored MDM configuration profiles for Apple devices in seconds by describing the settings you need in plain language.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | | | ✅ | |
## How to set it up
Describe the configuration you want in plain language. For example:
* *"Disable Bluetooth on all devices"*
* *"Set the DNS servers to 1.1.1.1 and 8.8.8.8"*
* *"Enable automatic screen lock after 2 minutes of inactivity"*
Review the generated profile — Primo will show you the resulting configuration before deployment.
Always review the generated profile before deploying. AI-generated configurations may require adjustments depending on your specific environment. Test on a small device group before rolling out broadly.
Adjust any settings if needed, then save and apply the control to the relevant device group.
## How it works
The AI engine produces a standard Apple `.mobileconfig` profile based on your description. The generated profile:
* Uses native Apple MDM payloads.
* Can be reviewed and edited before deployment.
* Is deployed to devices in the same way as any other Primo control.
**Tips for better results**
* Be specific about the setting and the desired value.
* Mention the context if relevant (e.g. "for shared devices" or "for the sales team").
* If the first result is not exactly right, refine your description and regenerate.
If you already have an existing `.mobileconfig` file you want to deploy, use the **Custom file** control instead.
# Google Chrome
Source: https://docs.getprimo.com/mdm/policies/google-chrome
Deploy managed Chrome settings, extensions, and homepage across macOS and Windows devices.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | | | |
## How to set it up
Toggle on **Primo Extension** to automatically discover SaaS applications and prevent shadow IT by scanning logins made with employees' professional Google accounts.
Under **Custom extension ID**, click **Add extension** to install Chrome extensions on targeted devices. Find each extension ID in the URL of its Chrome Web Store page.
Enter a URL to set as the default homepage.
* Toggle **Define "New tab page" as homepage** to use Chrome's new tab page instead.
* Toggle **Show home button** to display the home button in the toolbar.
Click **Add bookmark** to deploy managed bookmarks to all targeted devices.
Use the **Restore behavior on startup** dropdown to control what Chrome does when it launches.
* **Password manager**: allow users to save and autofill passwords in Chrome's built-in password manager.
* **Passkeys in password manager**: allow users to create and use passkeys in Chrome's built-in password manager.
* **Default browser setting**: let Chrome check whether it is the default browser and prompt users to set it as default.
Choose which devices to apply the control to: all devices, specific device groups, or a custom target.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
Primo pushes Chrome policies as a managed configuration profile (on macOS) or via registry keys (on Windows). Chrome detects these policies at startup and applies them automatically. Users cannot override managed settings.
A **Managed by your organization** notice appears in Chrome when enterprise policies are active — this is expected behavior.
# Google Play Store apps
Source: https://docs.getprimo.com/mdm/policies/google-play-store
Deploy managed apps to Android devices through Android Enterprise and the Google Play Store.
Google Play Store apps are distributed through Android Enterprise (managed Google Play). Primo pushes approved apps to enrolled Android devices through the managed work profile.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| | | | | ✅ |
## When to use
* You need to deploy apps to managed Android devices
* You want employees to access approved apps through the managed work profile
## Prerequisites
Android Enterprise must be configured and devices enrolled via the managed work profile or fully managed enrollment.
## Available options
* **Self-service** — the app appears in the managed Google Play store for employees to install on demand
Automatic install is not available for Android. Apps are made available through the managed Google Play store for self-service installation.
## How to add
1. Go to **MDM > Software** and click **Add app**.
2. Select **Google Play Store**.
3. Search for the app in the managed Google Play catalog.
4. Configure deployment options.
5. Click **Add software**.
## Gotchas
* Only **free** apps are supported through managed Google Play. Paid apps cannot be distributed this way.
* Zero Touch installation is not available for Android.
## App patching
| | |
| ------------------------------- | --------------------------------------------------------------- |
| **Keep installer updated** | ✅ Apps are always sourced from Google Play — always up to date |
| **Automatically patch devices** | ✅ Google Play manages updates automatically on enrolled devices |
# Lock MDM profiles pane
Source: https://docs.getprimo.com/mdm/policies/lock-mdm-profiles-pane
Block users from modifying the Profiles section in macOS System Settings, preventing them from viewing or removing MDM profiles.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | | | | |
## How to set it up
No additional configuration is required. Choose which devices to apply the control to: all macOS devices, specific device groups, or a custom target.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
Primo pushes an MDM restriction that removes the **Profiles** entry from System Settings. Users can no longer navigate to that section, view installed profiles, or attempt to remove them.
This control restricts the user-facing interface only. IT administrators can still view and manage profiles from the Primo dashboard and device panel.
# Platform SSO with Entra
Source: https://docs.getprimo.com/mdm/policies/mac-login-entra
Replace local macOS logins with Microsoft Entra ID single sign-on so employees use their corporate credentials to unlock their Mac.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | | | | |
## How to set it up
Before deploying this control, connect Primo to your Entra tenant in **Settings > MDM > Integrations**.
Select the authentication method from the dropdown:
* **Secure enclave** — uses the device's secure enclave to bind credentials, providing the strongest level of security.
Deploying this control will automatically install the app required for Entra Platform SSO on targeted devices.
Choose which devices to apply the control to: all macOS devices, specific device groups, or a custom target.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
Primo uses macOS Platform Single Sign-On (Platform SSO), introduced in macOS 13, to integrate the login window with Entra ID. When a user logs in, macOS validates the credentials against Entra ID and stores the resulting token in the Keychain for SSO to browser and app sign-ins.
Offline login is supported — if the device cannot reach Entra ID, macOS falls back to locally cached credentials.
The first login after enabling this control requires an active internet connection to establish the Entra ID binding on the device.
# Admin management
Source: https://docs.getprimo.com/mdm/policies/manage-admin-accounts
Deploy and manage local administrator accounts across your fleet — with per-device random passwords, privilege management, and full visibility from the Primo cockpit.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | | | |
## How to set it up
Coming soon: the ability to facilitate privilege escalation (giving temporary administrator access). In the meantime, you can use tools like Privileges and MakeMeAdmin for these actions.
Enter the username of the administrator account to create.
* **Random password** — generated per device (recommended)
* **Fixed password** — identical across all targeted devices
Enable **Demote non-matching accounts** to automatically reduce other users to standard access.
Save and apply to the relevant device group.
## Modify or remove the control
After activation, the username of the admin account to be created cannot be edited.
To update it, disable the policy then re-enable it with new settings. Disabling the policy stops enforcement but does **not** delete the administrator account or its password.
## How it works
The control creates a local administrator account and stores the password in the Primo cockpit.
**Removing administrator access** — it is not currently possible to remove administrator rights from an account if it is the only one with a **SecureToken** on the device. SecureToken is a macOS-specific access key required to activate FileVault encryption. Primo is working to support SecureToken transfer to allow this.
The control creates a local administrator account and stores the password. Password options (random or fixed) and privilege reduction work the same as on macOS.
# Desktop SSO with Okta
Source: https://docs.getprimo.com/mdm/policies/okta-windows
Configure Okta Device Access on managed Windows devices so employees authenticate with Okta Verify at the Windows login screen and gain SSO access to Okta-connected apps without re-authenticating.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| | ✅ | | | |
## Configure Desktop SSO
1. Go to **Admin Console > Applications > Applications > Browse App Catalog**
2. Search for **Desktop MFA for Windows** and click **Add integration**
> If the integration is unavailable, contact your Okta Account Manager — Okta Device Access is a paid add-on. If you already set up [Platform SSO with Okta](/mdm/policies/set-up-okta) for macOS, it is already enabled.
3. Open the app and go to the **General** tab
4. Note the **Client ID** and **Client Secret** — you will need both in Step 4
1. Go to **Admin Console > Security > Authenticators** and confirm **Okta Verify** is active
2. Go to **Security > Authenticator enrollment** and ensure users in scope are required to enroll in Okta Verify
Go to the software library and add **Okta Verify for Windows** to the profile targeting your Windows devices.
Complete this step before pushing the ADMX settings in the next step. Applying the login-screen configuration before Okta Verify is installed will disrupt the Windows login experience.
1. Go to **[csp-builder.getprimo.com](https://csp-builder.getprimo.com)**
2. Load the **Okta Device Access** ADMX template
The Okta ADMX will be available directly in the CSP Builder soon. In the meantime, download `OktaODA.admx` and `OktaODA.adml` from the [Okta Group Policy Templates article](https://support.okta.com/help/s/article/deploying-desktop-mfa-for-windows-using-group-policy-templates) and upload them manually.
3. Configure the following settings:
* **OrgUrl** — your Okta domain (e.g. `yourorganization.okta.com`)
* **ClientId** — from the Desktop MFA app
* **ClientSecret** — from the Desktop MFA app
4. Export the generated CSP policy and apply it to the profile targeting your Windows devices
Device-Bound SSO extends the Desktop MFA login into a persistent Okta session, so users access Okta-connected apps without a second sign-in.
**Enable the feature in Okta:**
1. Go to **Admin Console > Settings > Feature Manager** and activate **Device-Bound Single Sign-On** (Early Access)
2. Go to **Security > Device integrations > Device Access** tab
3. Add a **Static SCEP certificate authority** and note the **SCEP URL** and **SCEP challenge**
**Deploy the SCEP certificate via Primo:**
4\. Create a SCEP certificate profile and deploy it to your Windows devices
> Apply the profile at **Computer level**, not User level.
**Configure authentication policies in Okta:**
5\. Go to **Admin Console > Security > Authentication Policies**
6\. Open or create a policy for the Okta-connected apps you want to protect
7\. Add a rule for registered, Okta-joined devices:
* Set **Device State** to **Registered**
* Add the expression: `device.provider.deviceAccess.joined == true`
8. Configure the rule to grant access using the device session
Device-Bound SSO requires Okta Verify 6.6.2 or later. Update Okta Verify on your devices before activating this feature — enabling Device-Bound SSO registry settings on earlier versions can lock users out of Windows.
## How it works
When a user locks or wakes their Windows device, Okta Verify intercepts the login screen via a **Windows Credential Provider** installed by the ADMX settings. The user authenticates using Okta Verify — push notification, TOTP, or a FIDO2 key — and Windows unlocks.
With Device-Bound SSO enabled, Okta creates a hardware-bound session tied to the device's secure hardware at login time. When the user opens an Okta-connected app, Okta evaluates the device session against the app's authentication policy. If the device is Okta-joined and meets the assurance requirements, Okta grants access silently with no additional authentication challenge.
# Password and screenlock
Source: https://docs.getprimo.com/mdm/policies/password-policy
Set password rules and screen lock preferences to keep devices secure.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | | ✅ | ✅ |
## How to set it up
Set the **Screenlock** timeout to define how long a device can be idle before locking.
Configure password strength and renewal settings. Available options vary by platform:
* **Password strength** and **Allow simple** (whether simple passwords are permitted)
* **Password renewal** interval
* **Force password change at next login** toggle
Enabling **Force password change at next login** is not recommended if admin accounts are managed by the Admin Management control — it will also enforce a password change for those accounts.
* **Password strength** and **Password renewal** (under Password Settings)
On Windows, applying password length and complexity rules forces all accounts to change their password at the next sign-in.
* **Passcode strength**
* **Password strength** and **Password renewal**
Under **PIN Settings**, enter your **Tenant ID** (Windows Azure Active Directory Tenant ID) to enable PIN management. Then set **PIN strength** and **PIN renewal**.
If PIN settings are not configured, password policy applies to the PIN as well.
Choose which devices to apply the control to: all devices, specific device groups, or a custom target.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
Password and screen lock rules are enforced via MDM. The policy does not require an immediate password reset when first applied — renewal and strength requirements take effect at the next password change cycle.
Due to a macOS behavior, the screen lock value enforced by Primo may not appear grayed out in System Settings. Even if users appear to be able to select a different timeout, the MDM-enforced value always takes priority.
**Implicit password requirements on macOS:**
* Cannot contain repeated sequences of the same character (e.g. `sss`, `fff`)
* Cannot use consecutive identical characters
* Certain keywords and easily guessable patterns are not allowed
Available on macOS 13 and later, except macOS Sonoma 14.0–14.2.
Password settings and screen lock are enforced via MDM policy. PIN settings require an Azure Active Directory Tenant ID and apply separately from the account password.
* **Password renewal**: does not require an immediate reset — based on the last password modification date.
* **PIN renewal**: forces the PIN update at the next login if it does not comply.
Passcode strength and screen lock settings apply to supervised iOS and iPadOS devices.
Screen lock type, password strength, and password renewal are enforced on enrolled Android devices.
## Troubleshooting
**A new password is being rejected**
* Check for repeated characters (e.g. `sss`, `aaa`) or consecutive letters
* Avoid reserved words or easily guessable patterns
* Verify the password meets the configured length and complexity rules
# recoveryOS protection
Source: https://docs.getprimo.com/mdm/policies/recoveros-protection
Configure recoveryOS settings on macOS devices to prevent unauthorized access to recovery tools.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | | | | |
## How to set it up
No additional configuration is required. Choose which devices to apply the control to: all macOS devices, specific device groups, or a custom target.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
Primo delivers a macOS security configuration payload via MDM that applies restrictions to the recoveryOS environment. These settings are enforced at a firmware level on Apple Silicon Macs and at the security policy level on Intel Macs.
On Apple Silicon Macs, recoveryOS restrictions are integrated with the Secure Enclave. Full enforcement requires that the device is enrolled in MDM with the appropriate supervision level.
# Remote access
Source: https://docs.getprimo.com/mdm/policies/remote-management
Deploy RustDesk to enable encrypted remote access and screen sharing on managed devices.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | ✅ | | |
## How to set it up
No additional configuration is required. Choose which devices to apply the control to: all devices, specific device groups, or a custom target.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
Once deployed, Primo automatically installs the RustDesk agent on targeted devices via MDM. No user interaction or manual installation is required.
Sessions are initiated from the device panel in Primo — no passwords or codes are shared with users. Every session is encrypted.
On macOS, the user will be prompted to grant screen sharing permissions on first use. These permissions cannot be deployed via MDM and require a one-time approval from the user. After that, subsequent sessions start without any user interaction.
### Start a remote session
1. Open the device panel for the device you want to connect to.
2. Find the **Remote Access** card and click **Start session**.
You can run the session in your browser or through the local RustDesk app. It may take up to 30 seconds for the session to be ready.
# Screen capture blocking
Source: https://docs.getprimo.com/mdm/policies/screen-capture-blocking
Block screenshots and screen recording on macOS devices to protect sensitive content.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | | | | |
## How to set it up
No additional configuration is required. Choose which devices to apply the control to: all macOS devices, specific device groups, or a custom target.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
Primo pushes an MDM restriction that disables the macOS screenshot and screen recording APIs. Users cannot take screenshots using keyboard shortcuts or capture their screen through any application.
# SecureToken rules
Source: https://docs.getprimo.com/mdm/policies/secure-token
The secure token is a critical security identifier in macOS that enables actions like changing passwords and creating user accounts, ensuring compliance with Apple's security standards and proper user management through Primo.
This article explains what the **secure token** is on macOS, its role in local user management, and why it is required for actions such as changing user passwords or creating new user accounts.
## What is the secure token?
The **secure token** is a security identifier generated by macOS and linked to a local user account. It applies to macOS 10.13 and later on APFS volumes.
It enables data encryption and decryption through **FileVault**. A user with a secure token is considered "authorized" to perform sensitive system actions such as:
* Enabling or disabling FileVault
* Changing another local user's password (if the user has a secure token)
* Creating a new local user
* Granting a secure token to another account
Without a secure token, these operations fail, even when run from an administrator account.
A secure token is **granted**, not transferred. Several accounts on the same device can hold a secure token at the same time, so you never have to remove one account's token to give a token to another account.
## Why the secure token matters
Primo relies on the secure token to manage macOS users securely.
When you reset a password or create a new user through Primo, macOS requires an account that holds a secure token to initiate the action.
This ensures:
* Compliance with Apple's security requirements
* Continued access to the FileVault-encrypted disk
* Proper execution of user management actions
## Check the secure token status from the dashboard
The dashboard displays the secure token status under the **Users** tab of the relevant device.
Use it to verify whether the macOS administrator account used by Primo holds an active secure token.
To ensure proper user management, make sure the administrator account linked to the device has a secure token.
To check the status locally on the device, run:
```bash theme={null}
sudo sysadminctl -secureTokenStatus
```
## Grant or revoke a secure token
Both commands run locally on the device.
To grant a secure token to an account:
```bash theme={null}
sysadminctl -secureTokenOn -password -adminUser -adminPassword
```
To revoke the secure token of an account:
```bash theme={null}
sysadminctl -secureTokenOff -password -adminUser -adminPassword
```
In both cases you need the password of the account concerned **and** the password of an administrator account that already holds a secure token. This is an Apple requirement: changing the secure token status of a user with `sysadminctl` always requires the user name and password of an existing secure token–enabled administrator. There is no way to do it remotely without these passwords.
You can pass `-` instead of a password to be prompted for it interactively, which keeps passwords out of your shell history.
Every device must keep at least one account with a secure token. If the last one is revoked, nobody can unlock the disk at startup and the device becomes inaccessible.
Both `sysadminctl` and System Settings prevent the deletion of the last administrator or secure token–enabled user.
The cockpit can take up to 24 hours to update the local account status on the device's users tab.
## Bootstrap token and volume ownership
The **bootstrap token** is the mechanism that lets macOS grant a secure token at first login, without anyone entering credentials manually. Apple documents the following behavior:
* On macOS 11 and later, setting the initial password for the very first user on the device results in that user being granted a secure token.
* On macOS 11 and later, if macOS doesn't grant a secure token at creation, and if a bootstrap token is available from the device management service, it grants a secure token to the local user when they log in.
* On macOS 10.15.4 and later, macOS generates and escrows a bootstrap token to the device management service on the first login by any secure token–enabled user, if the service supports the feature.
On a device with Apple silicon, the secure token also determines **volume ownership**, which controls startup security settings and authorizes software updates and erasing all content and settings:
* The user that first claimed the device by configuring it for their use is granted a secure token and becomes the first volume owner.
* When a bootstrap token is available and in use, it also becomes a volume owner, and it grants volume ownership status to additional accounts as it grants them secure tokens.
To check volume owners and the bootstrap token state locally:
```bash theme={null}
sudo diskutil apfs listUsers /
sudo profiles status -type bootstraptoken
```
`listUsers` returns volume owners by GUID. To map a GUID back to an account, search for its `GeneratedUID`:
```bash theme={null}
dscl . -search /Users GeneratedUID
```
## Secure token behaviors (macOS only)
| Creation method | Admin account | Non-admin account |
| ------------------------------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------ |
| Created by Primo during ZTD | SecureToken automatically enabled | No SecureToken provided |
| Created automatically by "Admin account" policy | SecureToken provided on first login of the account | No SecureToken provided |
| Created manually by customer via Primo | SecureToken provided on first login of the account | No SecureToken provided |
| Created manually by customer locally | SecureToken provided if created from admin account with SecureToken | No SecureToken provided |
| Created via sysadminctl by customer locally or remotely | SecureToken provided if created using admin with SecureToken | SecureToken provided if created using admin with SecureToken |
## Troubleshoot secure token issues
| Symptom | Cause | Resolution |
| -------------------------------------------------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Granting a secure token fails on the administrator credentials | The administrator account you used does not itself hold a secure token | Check the status with `sysadminctl -secureTokenStatus`, then run the command again with an account that holds one |
| An account has no secure token although the device is managed | The account was created without a token and has not logged in yet | Have the user log in once, then check the status again |
| The account that holds the token is not an administrator | Another user claimed the device first and was granted the first secure token | Use that account's credentials as `-adminUser` to grant tokens, promoting it to administrator first if required |
# Platform SSO with Okta
Source: https://docs.getprimo.com/mdm/policies/set-up-okta
Integrate Okta as the authentication provider for managed Mac devices using Apple's Platform Single Sign-On so employees log in with their Okta credentials and SSO propagates to all Okta-connected apps.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | | | | |
## How to set it up
1. Go to **Admin Console > Applications > Applications > Browse App Catalog**
2. Search for **Platform Single Sign-On for macOS**
3. Click **Add integration**
> If the message *This feature isn't enabled* appears, contact your Okta Account Manager to enable Okta Device Access (paid feature).
4. Open the app from your application list
5. In the **General** tab, rename the app label if needed
6. In the **Sign On** tab, make note of the **Client ID** (required for MDM configuration)
7. In the **Assignments** tab, assign the app to the relevant users or groups
1. Go to **Admin Console > Security > Device integrations**
2. Ensure the **Device Access** tab is visible (next to *Endpoint Management*)
> If the tab is missing, Okta Device Access is not yet enabled
3. Add a **Static SCEP certificate authority**
4. Make note of the following:
* **SCEP certificate URL**
* **SCEP certificate challenge**
1. From the Okta Admin Console, go to **Settings > Downloads**
2. Download **Okta Verify for macOS**
3. Add the app to Fleet as software:
* Upload the application file
* Do not enable automatic deployment or self-service
* **Primo will automatically adjust settings to handle deployment**
Make sure to save the following details for the next step:
* **Okta domain** (e.g. `yourorganization.okta.com`)
* **Client ID** (from the Platform Single Sign-On application)
* **SCEP certificate URL**
* **SCEP certificate challenge**
Go to a profile: [https://app.getprimo.com/profiles](https://app.getprimo.com/profiles)
1. Enable the **Okta Platform SSO** setting
2. Enter the required information (domain, Client ID, SCEP URL, and Challenge)
3. Save the changes
Okta Platform SSO will then be activated on all devices targeted by the profile.
The deployment may take several minutes to complete, as Okta Verify must be installed on all targeted devices.
# USB storage blocking
Source: https://docs.getprimo.com/mdm/policies/usb-storage-blocking
Prevent USB keys, SD cards, and other removable storage from connecting to managed devices.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | ✅ | | |
## Set up the control
On Windows, choose the **USB storage access mode** from the dropdown:
* **Block** — prevents all removable storage devices from connecting.
Choose which devices to apply the control to: all devices, specific device groups, or a custom target.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
Primo pushes an MDM restriction that blocks removable storage devices from mounting. No additional configuration is required.
Primo deploys an MDM policy that blocks the installation and use of removable storage devices based on the configured access mode. Blocked devices appear in Device Manager and users see a notification that the device cannot be used.
Primo applies a configuration that blocks UI-based mounting of removable storage devices — for example, prompts from the desktop file manager when a USB drive is connected. The policy is applied system-wide and applies regardless of which user is logged in.
The control does not block manual mounting from the command line. Users with sufficient privileges can still mount USB storage using `mount`.
## Troubleshooting
**A user mounted a USB drive from the terminal after applying the control**
* This is expected behavior on Linux. USB storage blocking only blocks UI-based mounting. Command-line mounting with `mount` is not restricted by this control.
# WiFi
Source: https://docs.getprimo.com/mdm/policies/wifi
Push WiFi settings to managed devices so employees connect to company networks automatically without entering credentials manually.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | ✅ | ✅ | ✅ |
## How to set it up
* **Network name**: the SSID of the WiFi network.
* **Encryption type**: select the security type (e.g. WPA2).
* **Network password**: the password for the network.
Choose which devices to apply the control to: all devices, specific device groups, or a custom target.
## Modify or remove the control
Disable the control from the profile settings. Disabling stops enforcement but does not remove existing configurations from devices.
## How it works
Primo pushes the WiFi configuration as a managed network profile via MDM. Devices connect automatically when the network is in range. Users do not need to enter credentials manually.
# Account-driven device enrollment
Source: https://docs.getprimo.com/mdm/rollout/account-driven-enrollment
Enroll iOS, iPadOS, and macOS devices using Account-driven Device Enrollment — a privacy-preserving method where employees sign in with their Managed Apple ID to enroll their device.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----------- | ------- | ----- | ------------ | ------- |
| Coming soon | ❌ | ❌ | ✅ (`16+`) | ❌ |
## Prerequisites
* **Apple Business account** — your organization must have an Apple Business account.
* **Identity provider federation** — your identity provider (Google Workspace or Microsoft Entra) must be federated with Apple Business so that employees can authenticate with their corporate credentials.
## How it works
They tap **Sign in to work or school** (or go to **Settings > General > VPN & Device Management**) and enter their work email address.
The device performs a service discovery lookup on the email domain and contacts your organization's enrollment server.
They sign in with their corporate credentials via your federated identity provider (Google Workspace or Microsoft Entra).
A separate, cryptographically isolated **work partition** is created. Corporate apps and data live in this partition — personal apps and data remain invisible to the organization.
## Related articles
* [Enrollment methods](/mdm/rollout/enrollment-methods)
* [Set up Zero Touch for Apple](/mdm/zero-touch/zero-touch-macs)
# Employee guide & FAQ
Source: https://docs.getprimo.com/mdm/rollout/employee-enrollment-guide
Step-by-step instructions for employees to install the Primo MDM agent on their device, with answers to common questions.
This guide walks you through installing the Primo MDM agent. The installation takes less than 2 minutes and requires no technical skills.
You must have **administrator rights** on the device to complete the installation. If you do not, contact your IT team.
## Enroll your device
* **From the invitation email:** open the email titled "Invite to join \ on Primo" and click **Enroll my computer on Primo**.
* **From a direct link:** open the link shared by your IT team — you'll land directly on the enrollment page.
Enter your professional email address (or personal email if you're new and don't have one yet), then enter the **6-digit verification code** sent to that address.
After signing in, Primo will guide you through installation for your operating system.
If a device is already assigned to you, select it and click **Enroll**. Otherwise, click **Deploy MDM on another device** and select your OS.
**macOS**
1. Download and open **primo-enrollment.mobileconfig**.
2. Open **System Settings > General > Device Management**.
3. Select the profile and click **Enroll**, then enter your administrator password.
> If the installer is blocked, go to **System Settings > Privacy & Security** and click **Open Anyway**.
**Windows**
1. Double-click **primo-enrollment.msi**.
2. Click **Yes** in the security prompt.
**Linux**
1. Download the enrollment package for your distribution.
2. Run the installer using your package manager or the provided shell script.
**iOS / iPadOS**
1. Open the enrollment link on your device.
2. Go to **Settings > General > Device Management**.
3. Select and install the **MDM Primo** profile.
**Android**
Android offers two enrollment modes. Pick the one your IT team told you to use:
* **Personal (work profile)** — for a personal device. Company apps and data stay in a separate work profile; your personal data stays private.
1. Open the **Personal (work profile)** enrollment link on your Android device, or scan the QR code shown next to it.
2. Tap **Enroll** and follow the on-screen steps to create the work profile.
* **Company-owned (fully managed)** — for a new or factory-reset company device. Primo manages the whole device.
1. Open the **Company-owned (fully managed)** link on a computer or tablet. A provisioning QR code appears — keep it open.
2. Factory-reset the Android device and power it on. Stop on the welcome screen.
3. Tap the welcome screen 6 times to open the QR code scanner, then scan the provisioning QR code from step 1.
Once the agent is installed, you'll receive a confirmation email and your device will appear in the Primo dashboard.
***
## FAQ
### How long does installation take?
Less than 2 minutes from start to finish.
### Will MDM slow down my device?
The Fleet agent is lightweight and designed for minimal performance impact. If you notice slowdowns after enrollment, contact your IT team.
### Can Primo see my personal files or browsing history?
No. The MDM does not access documents, browser history, messages, or personal app data. It only collects device metadata — OS version, installed app names, and compliance status.
### My device is asking me to change my password but won't let me
This is a known macOS issue that can occur after installing MDM on a device with an active password policy. Restart your computer — the password change will work correctly after the reboot.
### My Mac says it's already managed by an MDM
Check whether the installed profile is named **Primo Enrollment** or **\ Enrollment**. If so, the device may already be enrolled — confirm with your IT team.
If it's a different profile, ask your IT team for the procedure to remove the existing MDM before installing Primo.
### I used my personal email — is that a problem?
No. Using your personal email for authentication has no impact on enrollment.
### The installer download is blocked by the browser
Allow the download in your browser's security settings, or ask your IT team for an alternative method.
### The enrollment page shows an error
Make sure you're using the correct email address and that your 6-digit code hasn't expired (codes are valid for 10 minutes). Request a new code if needed.
### The device doesn't appear in the dashboard after installation
Wait a few minutes — enrollment can take up to 5 minutes after the agent is installed. If the device still doesn't appear, contact your IT team.
### Who do I contact if something goes wrong?
Contact your IT team – Primo Support is only for company admins.
# Enrollment methods
Source: https://docs.getprimo.com/mdm/rollout/enrollment-methods
Compare the available methods for enrolling devices into Primo and choose the right approach for your organisation, based on your existing setup, platform mix, and whether you want the process to be admin-driven or employee-driven.
## By method
| Method | When to use | Compatibility | Driven by | Pros | Cons |
| -------------------------------------------------------------------------- | ------------------------------------------------------- | --------------------------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| [Zero Touch](/mdm/zero-touch/zero-touch-macs) | Gold standard - move towards this little by little | ✅ macOS ✅ Windows ✅ iOS/iPadOS ❌ Android (coming soon) | Admin |
Highest level of control
Devices cannot be activated without authentication — protection against theft
|
Requires initial setup in ABM or Autopilot
Not compatible with devices not registered in ABM or Autopilot
|
| [Account-driven Device Enrollment](/mdm/rollout/account-driven-enrollment) | If you federate accounts in Apple Business | ❌ macOS (coming soon) ✅ iOS/iPadOS | Employee |
Privacy-preserving
Separates work and personal data on the device
|
Requires federation in Apple Business
|
| [Silent agent deployment](/mdm/rollout/silent-agent-deployment) | If you already can deploy packages (migration scenario) | ✅ macOS ✅ Windows ✅ Linux | Admin |
Centralised and silent
No employee interaction needed
|
Mac: once the agent is installed, the MDM profile still needs to be accepted by the employee
|
| [Migrating with Apple Business](/mdm/zero-touch/zero-touch-macs) | For devices in Apple Business and on macOS Tahoe 26+ | ✅ macOS ✅ iOS/iPadOS | Admin |
Reassigns devices already in Apple Business to Primo without wiping
Works on devices already deployed in the field
|
Requires an existing Apple Business account with devices already assigned
Only works with macOS Tahoe 26+
|
## By platform
* [Zero Touch](/mdm/zero-touch/zero-touch-macs) — gold standard; use this for new devices purchased through Primo or an authorized reseller
* [Migrating with Apple Business](/mdm/zero-touch/zero-touch-macs) — for devices already assigned in Apple Business running macOS Tahoe 26+
* [Silent agent deployment](/mdm/rollout/silent-agent-deployment) — if you already have a package deployment tool and need to migrate silently
* [Employee enrollment](/mdm/rollout/invite-employees) — always works as a fallback; relies on employee action
* [Zero Touch](/mdm/zero-touch/zero-touch-windows) — gold standard; use this for new devices enrolled via Windows Autopilot
* [Silent agent deployment](/mdm/rollout/silent-agent-deployment) — if you already have a package deployment tool and need to migrate silently
* [Employee enrollment](/mdm/rollout/invite-employees) — always works as a fallback; relies on employee action
* [Silent agent deployment](/mdm/rollout/silent-agent-deployment) — preferred if you have a package deployment tool
* [Employee enrollment](/mdm/rollout/invite-employees) — always works; relies on employee action
* [Zero Touch](/mdm/zero-touch/zero-touch-macs) — gold standard; use this for devices purchased through Primo or an authorized reseller and assigned in Apple Business
* [Migrating with Apple Business](/mdm/zero-touch/zero-touch-macs) — for devices already assigned in Apple Business
* [Account-driven Device Enrollment](/mdm/rollout/account-driven-enrollment) — if you federate accounts in Apple Business and want to preserve privacy on personal devices
* [Employee enrollment](/mdm/rollout/invite-employees) — always works as a fallback; relies on employee action
* [Employee enrollment](/mdm/rollout/invite-employees) — the only available method; employees enroll their own devices
# Employee enrollment
Source: https://docs.getprimo.com/mdm/rollout/invite-employees
Employee enrollment is the standard method for enrolling devices where the employee installs the Primo MDM agent themselves. It works on all supported platforms and requires no prior infrastructure.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | ✅ | ✅ | ✅ |
## Prerequisites
* Employees must have accounts in Primo.
## Invite your employees
### 1. Share your company enrollment portal
Every organization has a dedicated enrollment portal. Share it with employees via Slack, email, or any other channel:
```text theme={null}
https://app.getprimo.com/{company}/employee
```
### 2. Invite by email
Go to **Employees** and use the **Invite to MDM** action:
* **One employee** — open the employee profile and click **Invite to MDM**.
* **A selection** — select employees, click **Invite to MDM > Invite X selected employees**.
* **Everyone** — click **Invite to MDM > Invite matching employees**.
Each employee will be enrolled in MDM invitations. They will get a reminder to enroll every 7 days until you deactivate the invites or they enroll a device.
## Related articles
* [Enrollment methods](/mdm/rollout/enrollment-methods)
* [Employee guide & FAQ](/mdm/rollout/employee-enrollment-guide)
* [Communication resources](/mdm/rollout/mdm-rollout-resources)
# Communication resources
Source: https://docs.getprimo.com/mdm/rollout/mdm-rollout-resources
Email and Slack templates to communicate your MDM rollout to employees. We recommend giving clear deadlines to drive a quick, efficient rollout.
## Suggested rollout timeline
| Day | Actions |
| ------ | ---------------------------------------------------------------------- |
| Day 1 | Send the rollout email + enrollment invitations from the Primo cockpit |
| Day 3 | Check first enrollments; send a Slack/Teams reminder |
| Day 7 | Primo automatically re-sends the invitation to unenrolled employees |
| Day 10 | Send the reminder email to latecomers |
| Day 14 | Final reminder if needed |
## Email templates
### Initial email
> **Subject: Primo — Securing our devices**
>
> Hi all,
>
> We're rolling out **Primo**, our new device management solution, to secure our company equipment.
>
> You'll receive a separate email from [support@getprimo.com](mailto:support@getprimo.com) shortly with a personal installation link. **The installation takes less than 2 minutes** and won't disrupt your work.
>
> Once installed, Primo will apply a few security configurations to your device:
>
> * Password policy and screen lock
> * Disk encryption and recovery key storage
> * Automatic security updates
>
> Primo is not a monitoring tool — it cannot access your personal files, messages, or browsing history.
>
> Please complete the installation **by \[deadline]**. If you have any questions, reply to this email or contact [support@getprimo.com](mailto:support@getprimo.com).
>
> Thanks
### Reminder email
> **Subject: Reminder — Primo installation**
>
> Hi,
>
> We noticed you haven't installed **Primo** on your device yet. Please follow the instructions in the original invitation email to complete the installation.
>
> It takes less than 2 minutes and is required to keep our systems secure.
>
> If you need help, contact us or reach out to [support@getprimo.com](mailto:support@getprimo.com).
>
> Thanks
## Slack / Teams templates
### Initial message
> 🚀 **Primo deployment — action required**
>
> We're starting the rollout of **Primo**, our device management solution, today.
>
> You'll receive an email from [support@getprimo.com](mailto:support@getprimo.com) with your personal installation link. Installation takes less than 2 minutes — please complete it **by \[deadline]**.
>
> Questions? Contact us or write to [support@getprimo.com](mailto:support@getprimo.com).
### Reminder message
> ⚠️ **Reminder — Primo installation**
>
> A quick reminder for those who haven't installed **Primo** yet. Check your inbox for the installation email and complete the setup today.
>
> Need help? Contact us or write to [support@getprimo.com](mailto:support@getprimo.com).
## Related articles
* [Employee enrollment](/mdm/rollout/invite-employees)
* [Employee guide & FAQ](/mdm/rollout/employee-enrollment-guide)
# Migrate Macs using Apple Business
Source: https://docs.getprimo.com/mdm/rollout/migrating-macs-using-abm
Reassign Macs from a previous MDM to Primo via Apple Business — no device wipe, no data loss.
Move Macs from your previous Mobile Device Management (MDM) solution to Primo by
reassigning them in Apple Business. The migration never requires a device wipe:
employees keep their data, apps, and session.
This article covers organization-owned Macs registered in Apple Business. If your
Macs are not in Apple Business, choose another approach in
[enrollment methods](/mdm/rollout/enrollment-methods). iPhone and iPad follow a
different migration process not covered here.
## Prerequisites
* The Mac is **organization-owned** and **registered in Apple Business** —
purchased from Apple or a reseller linked to your organization, or added with
Apple Configurator
* The Mac is enrolled with your previous MDM through
**Automated Device Enrollment (ADE)**
* macOS 11 or later
* **Administrator access** to Apple Business, with a role allowed to set
migration deadlines
* Primo already **connected to Apple Business** ([set this up first](/mdm/zero-touch/zero-touch-macs))
* If you deploy apps purchased in volume: your
**Volume Purchase Program (VPP) token** transferred to Primo before you start,
following the migration order in
[App Store apps](/mdm/policies/app-store-apps)
Macs added with Apple Configurator can only migrate after their 30-day
provisional enrollment period. On macOS 26, Macs that left Automated Device
Enrollment and re-enrolled through profile-based enrollment can still migrate.
## Reassign the Macs in Apple Business
Go to [business.apple.com](https://business.apple.com/) and sign in.
Go to **Devices**, then select the Mac(s) you want to reassign.
Click **Edit MDM Server**, select your Primo MDM server as the destination,
and confirm the assignment.
Apple Business asks for a deadline to complete enrollment. Employees can
postpone the migration until then. Keep the deadline within 30 days if you
deploy apps purchased in volume.
Reassigning a Mac does not start the migration on its own. Without a deadline,
the Mac never receives a migration prompt — and nothing reports the failure, in
Apple Business, in the dashboard, or on the device. Set the deadline in the
same session as the reassignment.
This deadline is set in Apple Business and applies to the migration only. It is
unrelated to the OS update deadline you configure in the dashboard, which
enforces a minimum macOS version.
What happens next depends on the macOS version. Apple numbers macOS by year, so
macOS 26 (Tahoe) directly follows macOS 15 (Sequoia) — there are no versions 16
through 25.
If your previous MDM delivers the **Wi-Fi configuration** through a profile,
the Mac loses that profile the moment it unenrolls — whether it unenrolls itself
on macOS 26 or you remove the profile on earlier versions. Without network
access it cannot reach Primo to complete enrollment. Confirm affected Macs can
join a network another way (Ethernet, or a manually configured Wi-Fi network)
before you start.
## Migrate on macOS 26 and later
macOS 26 supports Apple's native MDM migration.
**Do not unenroll the Macs from your previous MDM** — each Mac unenrolls itself
during the migration.
1. Apple notifies the Mac that a migration is pending.
2. The employee sees a migration prompt with the deadline you set. They can start
the migration immediately or postpone it.
3. Notifications repeat daily, then hourly during the last 24 hours, then at 60,
30, 10, and 1 minute before the deadline.
4. At the deadline, the Mac shows a full-screen prompt the employee cannot
dismiss. The Mac then unenrolls from the previous MDM and re-enrolls with
Primo.
The Mac is never wiped — whether the employee starts the migration or the
deadline enforces it.
The unenrollment signal sent to your previous MDM is best-effort. After the
migration completes, delete any device records that remain in the previous
console manually.
## Migrate on macOS 15 and earlier
Apple's native migration is not available before macOS 26. The migration relies
on enrollment enforcement instead: a Mac assigned to Primo in Apple Business and
no longer enrolled with an MDM prompts the employee to enroll.
Follow the steps above.
Remove the management profile from the previous MDM console. Deleting the
device record is not enough — the profile must be removed from the Mac
itself. Employees cannot do this: on a supervised Mac the profile is not
user-removable.
The Mac re-checks its Apple Business assignment periodically — up to 24
hours, or at the next restart or network change. To trigger it immediately,
run this command on the Mac with administrator rights:
```bash theme={null}
sudo profiles renew -type enrollment
```
The Mac shows a Remote Management notification asking the employee to enroll.
This is a one-time approval — no wipe, no data loss.
## Review what changes on the Mac
* **Data and session** — untouched. Local accounts, files, and settings remain.
* **Apps** — remain installed. Apps managed by the previous MDM become
unmanaged; Primo redeploys apps according to your policies.
* **Apps purchased in volume** — may be temporarily removed from devices while
the VPP link switches over, then redeploy automatically once the new link is
active.
* **Configuration profiles** — the migration removes all profiles from the
previous MDM. Primo applies its own profiles after enrollment.
* **FileVault** — the disk stays encrypted throughout. The recovery key escrowed
by your previous MDM becomes unavailable once that service is decommissioned.
Primo escrows a new recovery key after enrollment, not during it.
* **Activation Lock** — the migration removes the previous service's Activation
Lock, and its bypass codes become invalid. Primo retrieves the new bypass code
on a recurring check, which can take up to a week.
Employees regain use of the Mac as soon as enrollment completes — before the
FileVault recovery key, bootstrap token, and Activation Lock bypass code are
escrowed. Until those land, you have no recovery key and no bypass code for
that Mac. Always run the verification below.
## Verify the migration
The device record shows the Mac as enrolled and supervised.
On the device, open **System Settings > General > VPN & Device Management**.
The previous MDM profile should be gone, and a Primo management profile
present. To check from the command line instead:
```bash theme={null}
sudo profiles status -type enrollment
```
Expected configuration profiles and app deployments appear on the device
record.
If no key appears, ask the employee to restart the Mac and wait for the next
sync — the key cannot be escrowed until the bootstrap token is in place.
Confirm a bypass code is escrowed. See
[Activation Lock bypass code escrow](/mdm/guides/activation-lock-bypass).
## Troubleshooting
**Apple Business does not offer a migration deadline for a Mac**
* The Mac does not meet the migration requirements. Bulk actions fail for it —
check the Apple Business activity log for the failed action.
* Confirm the Mac is enrolled through Automated Device Enrollment and is past
the 30-day provisional period if it was added with Apple Configurator.
**The Mac never shows a prompt**
* On macOS 26 and later, confirm a **migration deadline is set** in Apple
Business. This is the most common cause: reassignment alone does not trigger
the migration, and nothing reports the missing deadline.
* Confirm the reassignment is saved in Apple Business and the Mac is online.
* On macOS 15 and earlier, confirm you removed the previous management profile
from the Mac, then run `sudo profiles renew -type enrollment`.
* Check the enrollment state on the Mac itself to see whether the previous
profile is actually gone.
**The Mac has no network after unenrollment**
* The Mac displays the Wi-Fi network picker. The enrollment screen also offers a
**Choose a Wi-Fi network** link.
**You need to cancel a migration on macOS 26**
* Reassign the Mac back to the previous MDM server before the migration starts.
The device withdraws its migration prompts.
## What if the previous MDM is already decommissioned?
A Mac left on a decommissioned MDM is not lost. It keeps working and keeps all
its data — it simply becomes unmanaged: the previous profiles stay in place until
something removes them, and the employee notices nothing.
To bring it under management on macOS 15 and earlier, you still need to remove
the management profile, and you cannot do that without access to the previous
console — the employee cannot remove it either. Two options:
* Restore access to the previous MDM long enough to unenroll the Macs.
* Erase and re-enroll each Mac through zero-touch deployment. This wipes the
device — back up employee data first.
Before erasing, turn off **Find My** on the Mac, or confirm a valid Activation
Lock bypass code is available. A decommissioned MDM cannot hand over its bypass
code, and the migration invalidates it in any case. Erasing a Mac that still
has Find My enabled brings it back Activation-Locked and unusable. If you
cannot turn Find My off while the Mac still starts up, do not erase it. See
[Activation Lock bypass code escrow](/mdm/guides/activation-lock-bypass).
Retrieve any Activation Lock bypass codes you may need from the previous MDM
**before** decommissioning it. The migration invalidates them, and they cannot
be recovered afterwards.
## Contact
If Macs remain unenrolled after the deadline, or a FileVault recovery key never
appears, contact [support@getprimo.com](mailto:support@getprimo.com) with:
* The device serial numbers
* The macOS version on each device
* The name of your previous MDM solution
* The migration deadline you set in Apple Business
## Related articles
* [Set up zero-touch deployment for Macs](/mdm/zero-touch/zero-touch-macs)
* [Enrollment methods](/mdm/rollout/enrollment-methods)
* [Activation Lock bypass code escrow](/mdm/guides/activation-lock-bypass)
# Silent agent deployment
Source: https://docs.getprimo.com/mdm/rollout/silent-agent-deployment
Deploy the Primo MDM agent centrally and silently — using an existing MDM, Active Directory with GPO, or any package deployment system.
## Platform compatibility
| macOS | Windows | Linux | iOS / iPadOS | Android |
| ----- | ------- | ----- | ------------ | ------- |
| ✅ | ✅ | ✅ | ❌ | ❌ |
## Prerequisites
* An existing MDM, Active Directory with GPO, or equivalent system capable of deploying packages to your devices.
On **macOS**, once the Fleet agent is installed silently, the MDM enrollment profile still needs to be installed by the employee. For a fully touchless experience, use [Zero Touch for Apple](/mdm/zero-touch/zero-touch-macs) instead.
## Deploy via an existing MDM
Download the enrollment packages from **Devices > Enroll devices** in the Primo cockpit. Select the operating system and copy the package or download the installer.
Distribute the package through your existing MDM (Jamf, Intune, SCCM, etc.) as a silent install. The agent will check in with Primo automatically once installed.
## Migrate from another MDM
Enable **Windows MDM Automatic Migration** in **Settings > MDM**. Once enabled, Fleet will automatically migrate Windows devices enrolled with another MDM solution — no manual re-enrollment required.
**Migrating from Intune specifically**
If you have connected Intune and Entra ID, follow these steps before initiating migration:
Go to your Fleet MDM URL: `https://{company}.mdm.getprimo.com/settings/integrations/automatic-enrollment/windows`
Go to [entra.microsoft.com](https://entra.microsoft.com) and search for **Mobility**. Select **Intune**, then set both options to **None** and save.
* **One by one:** enroll the device in Primo — it will appear with the status "On in another MDM". Use the migration button in Primo to run the migration script.
* **All at once:** upload the migration script to Controls > Scripts, create a policy using the detection query below, and link the script to the policy.
```powershell theme={null}
$EnrollmentsPath = "HKLM:\SOFTWARE\Microsoft\Enrollments\"
$Enrollments = Get-ChildItem -Path $EnrollmentsPath
$DiscoveryServerFullUrls = @("INPUT_URL_HERE")
FoEach ($Enrollment in $Enrollments) {
$EnrollmentObject = Get-ItemProperty Registry::$Enrollment
if ($EnrollmentObject."DiscoveryServiceFullURL" -in $DiscoveryServerFullUrls ) {
$EnrollmentPath = $EnrollmentsPath + $EnrollmentObject."PSChildName"
Remove-Item -Path $EnrollmentPath -Recurse
& "C:\Windows\System32\deviceenroller.exe /c /AutoEnrollMDM"
}
}
```
Detection query (replace `INPUT_URL_HERE` with your Fleet MDM URL):
```sql theme={null}
SELECT 1 FROM registry
WHERE path LIKE 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\%%'
AND name = "DiscoveryServiceFullURL"
AND data NOT IN ("INPUT_URL_HERE")
```
For supervised devices registered in Apple Business Manager (ABM):
Go to **Settings > MDM > Apple** and complete the ABM connection.
In Apple Business Manager, reassign devices to Primo's MDM server. This does not erase device data.
From your previous MDM console, unenroll the devices. ABM does not remove them automatically.
Employees receive a **Remote Management** prompt on their device and are asked to install the Primo MDM profile.
## Related articles
* [Enrollment methods](/mdm/rollout/enrollment-methods)
* [Set up Zero Touch for Apple](/mdm/zero-touch/zero-touch-macs)
* [Set up Zero Touch for Windows](/mdm/zero-touch/zero-touch-windows)
# Script library
Source: https://docs.getprimo.com/mdm/scripts/script-library
Add, edit, download, and delete shell, Python, and PowerShell scripts you can run on macOS, Linux, and Windows devices.
The **Script library** is where you manage the scripts you can run on your fleet. Add a `.sh`, `.py`, or `.ps1` script once, then run it on any compatible device.
## Supported script types
| Extension | Platforms | Notes |
| --------- | ------------ | ----------------------------------------------------------------------------------------- |
| `.sh` | macOS, Linux | Must run under `/bin/sh`, `/bin/bash`, or `/bin/zsh`. |
| `.py` | macOS, Linux | Must start with a shebang that includes `python` (for example, `#!/usr/bin/env python3`). |
| `.ps1` | Windows | Runs in PowerShell. |
Each script is limited to **1 MiB** of content.
## Open the Script library
From the dashboard, open **Device Management**.
Select the **Scripts** tab.
You see one row per script with its name, type, and available actions.
## Add a script
Select **Add a script**.
Choose one of two ways:
* **Drag and drop** a `.sh`, `.py`, or `.ps1` file into the upload area. The form fills in the name, platform, and contents for you.
* **Fill in the fields manually**: pick a platform, enter a name ending in the matching extension, and paste the script into the editor.
Select **Save**.
The **Platform** selector owns the extension. Switching platforms rewrites the extension in the name, and typing a name with a matching trailing extension updates the platform. You can edit either field freely — they stay in sync only when the other field is unambiguous.
### Validation rules
Before saving, Primo checks that:
* The name ends in a supported extension (`.sh`, `.py`, or `.ps1`).
* The contents are 1 MiB or smaller.
* A `.py` script starts with a `python` shebang, for example:
```python theme={null}
#!/usr/bin/env python3
print("Hello from Primo")
```
* A `.sh` script uses a supported interpreter if it declares a shebang, for example `#!/bin/bash` or `#!/usr/bin/env bash`.
If a rule fails, **Save** stays disabled and the offending field shows the reason.
## Edit a script
On the script's row, open the actions menu and select **Edit**.
Edit the script in the editor.
Select **Save**.
You can only edit the **contents**. The **name** and **platform** stay locked, because renaming would change the script's type. To rename a script or change its type, delete it and create a new one.
**Save** stays disabled until you change the contents.
## Download a script
On the script's row, open the actions menu and select **Download**. The file downloads with the script's original name and extension.
## Delete a script
On the script's row, open the actions menu and select **Delete**.
Confirm in the dialog.
Past runs of the script remain in each device's script history — Primo keeps the name and contents used at run time. Any run that hadn't completed yet moves to **cancelled**.
## Permissions
| Action | Required permission |
| ----------------------------------- | ------------------- |
| View the library, download a script | `MDM_READ` |
| Add, edit, or delete a script | `MDM_WRITE` |
If you're missing a permission, the action stays visible but disabled and a tooltip explains why. In a **demo workspace**, only the confirm buttons in the modals are disabled — you can still open a script to read it.
# Settings
Source: https://docs.getprimo.com/mdm/settings
Configure your Primo MDM instance — integrations, enrollment behavior, notifications, and more.
The Settings page gives you an overview of your MDM status and access to all configuration options. Go to **MDM > Settings**.
## MDM status
Shows the activation status of each platform (Apple, Windows, Android, Linux) and the renewal date for your Apple MDM certificate.
## Integrations
Connected security, identity, and compliance integrations (e.g. SentinelOne, [Vanta](/mdm/integrations/vanta)). Manage connections from this section.
## MDM deployment
Shows the status of your MDM deployment integrations:
* **Apple Business Manager** — required for Zero Touch deployment on Apple devices
* **Windows Autopilot** — required for Zero Touch deployment on Windows devices
## Software
* **Volume Purchase Program** — shows the status of your VPP connection for Apple App Store app deployment. See [App Store Apps](/mdm/policies/app-store-apps).
## Settings
### Custom transparency URL
Overrides the default "Transparency" link in the Fleet Desktop menu with a URL of your choice, directing employees to your own resource.
### Organization support
Customizes the support link that appears in error messages, directing employees to your chosen support resource.
### MDM notifications
The email address that receives MDM-related notifications, such as confirmations of locks and wipes.
### Automatic unenrollment
When enabled, devices that remain offline for a specified number of days are automatically tagged and optionally purged. You can also choose to send a new MDM invite to the employee when their device is purged.
### Automatic Windows MDM migration
When enabled, Fleet automatically migrates Windows devices enrolled in another MDM solution to Primo.
### IdP during Zero-Touch Deployment
When enabled, employees are required to authenticate with your Identity Provider (IdP) during the Zero-Touch Deployment setup flow.
### Assignment suggestion
Uses AI to suggest device-to-employee assignments based on device data. You can enable suggestions only, or also allow Primo to automatically assign devices based on the suggestion.
### Device naming source
Controls which source manages device names:
* **MDM** — Primo manages the hostname and pushes it to the device
* **Device** — the device name syncs from the physical device into Primo
## MDM generic installer
Download a generic MDM enrollment installer for any platform. Useful for enrolling devices manually after initial setup.
Available for: macOS, macOS agent (`.pkg`), iOS, iPadOS, Android (Personal / work profile), Android (Company-owned / fully managed), Windows (x64), Windows (ARM64), Linux (Debian/Ubuntu), Linux (Fedora/CentOS), Linux (Arch).
Android exposes two enrollment modes side by side:
* **Personal (work profile)** — employee-driven enrollment on a personal device. An isolated work profile holds company apps and data; personal data stays private.
* **Company-owned (fully managed)** — IT-driven enrollment on a new or factory-reset company device. Primo manages the whole device.
See [Android](/mdm/get-started/initial-setup-android) for the end-to-end flow of each mode.
Use **Reset enrollment links** to invalidate existing installer links and generate new ones.
# Software installation status
Source: https://docs.getprimo.com/mdm/software-installation-status
See where every Primo-managed app stands on each targeted device — installed, in progress, failed, or ready to install — and install, update, or uninstall it from the dashboard.
Adding software to Primo tells the fleet what *should* be installed. Installation status tells you what actually *is* installed, device by device, and lets you act on the gaps without leaving the dashboard.
For every app you manage in Primo, you get:
* The install state on each device the app targets
* The version installed on the device versus the version your package offers
* Per-app counters across the fleet: how many devices have it, how many are still working on it, how many failed
* Install, reinstall, update, and uninstall actions on a single device
## What the list covers
The scope is deliberately narrow — two rules decide whether a device and an app appear together:
* **Primo-managed software only.** Only apps you added to **MDM > Software** are tracked. Apps an employee installed themselves are never listed, even though the agent can see them on the device.
* **Targeted devices only.** A device appears for an app only if the app's targeting resolves to it — either the app targets all devices on its platform, or the device belongs to one of the app's targeted device groups.
This is not a full software inventory of the device. If you need the complete list of every title detected on a device, open the device in Fleet.
## Where to find it
| Surface | What it shows |
| ---------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| **Software** tab in the device drawer | Every app targeting this device, with its status, versions, and actions |
| **Installed**, **In progress**, and **Failed** columns in **MDM > Software** | Device counts per app across the fleet |
| **Devices** tab on a software page | Every device this app targets, with its status and actions |
Open the device drawer from any device list, then select the **Software** tab. On a software page, the **Devices** tab sits next to **Setup**.
The three count columns are part of the default **All** view of the software table. If you use custom views, add them from the column picker.
## Install statuses
Primo reports four statuses. They are computed on the server from what Fleet knows about the device, so the dashboard, the counters, and the device list always agree.
| Status | Meaning |
| -------------------- | -------------------------------------------------------- |
| **Installed** | The app is present on the device |
| **In progress** | An install, update, or uninstall is queued or running |
| **Failed** | The app is not on the device and the last attempt failed |
| **Ready to install** | The app targets the device and has never been installed |
**Presence outranks failure.** An app that is still on the device reads **Installed** even if its last install or uninstall attempt failed. **Failed** always means the app is absent — which keeps the counters and the device list honest when you triage.
Hover an **In progress** status to see why it has not moved yet:
* If the device is online, the operation is running on it now.
* If the device is offline, the operation is queued and runs the next time the device comes online.
## Versions
The device drawer shows two version columns:
* **Installed version** — the version detected on the device
* **Library version** — the version your Primo package or App Store app offers
Either column can be empty. Fleet reports the installed version from device inventory, independently of the installs it tracks itself, so a freshly installed app or a package Fleet cannot fingerprint can read **Installed** with no version. When both versions are known and the library version is newer, the primary action becomes **Update**.
## Install, update, and uninstall
Each row exposes up to two actions. Primo picks the primary action from the status and the versions:
| Action | When it appears |
| ------------- | --------------------------------------------------------------- |
| **Install** | The app is **Ready to install**, or the last attempt **Failed** |
| **Reinstall** | The app is **Installed** and up to date |
| **Update** | The app is **Installed** and the library version is newer |
| **Uninstall** | The app is **Installed** and was deployed as a package |
Actions are requests, not instant results. Primo sends the command to the device and the row switches to **In progress**; the real status lands on the next sync.
**Uninstall** is not offered for:
* Apple App Store apps and `.ipa` apps — the store manages removal
* Apps Primo installs on every device it manages
* Software whose deployment is driven by an MDM control
An action can also be temporarily unavailable. Hover the button to see which:
| Tooltip | What to do |
| --------------------------------------------------------- | ---------------------------------------- |
| An install or uninstall is already running on this device | Wait for the current operation to finish |
| Turn on scripts for this device to install software | Enable scripts on the device, then retry |
| Turn on MDM for this device to install software | Enroll the device in MDM, then retry |
## Investigate a failure
On the **Devices** tab of a software page, a **Failed** row shows a **See in Fleet** link next to the status. Hover the link for the reason Fleet reported, and open it to read the full install output — the script result or the detection query that decided the app is missing.
Failures usually come down to one of these:
* The installer needs a flag or a pre-install step the package does not provide
* The detection query does not match how the app registers itself — see [How to find the right program name](/mdm/guides/find-program-name)
* The device did not meet a requirement of the installer, such as free disk space or a minimum OS version
## How the status refreshes
Each time a device checks in, Primo recomputes the status of every app targeting it. No scan to launch.
Adding, editing, or deleting software re-syncs the devices it used to target and the devices it now targets, so rows appear and disappear with the targeting.
Use **Refresh** in the device drawer to re-sync one device. On a software page, open the action menu and click **Refresh device software** to re-sync every device that app targets.
Refreshes fan out in the background, so counters and rows update a few seconds after the request. Right after you trigger an action or a refresh, the tables poll for a minute and update on their own. A newly added app reads zero on every counter until its first sync completes.
# Software types & capabilities
Source: https://docs.getprimo.com/mdm/software-types
Primo supports several software types across platforms, each with different deployment and management capabilities. Use this page to choose the right approach for your fleet.
## Per platform
| Platform | Software type | Prerequisites | Auto install | Self-service | Zero Touch | Keep installer updated | Auto patch |
| ---------------- | -------------------------------------------------- | -------------- | :----------: | :----------: | :--------: | :--------------------: | :--------: |
| **macOS** | Fleet-Maintained Apps | | ✅ | ✅ | ✅ | ✅ | ✅ |
| | Apple App Store | VPP connection | ✅ ¹ | ✅ | ✅ | ✅ | ✅ |
| | Custom software (`.pkg`) | | ✅ | ✅ | ✅ | ❌ | ❌ |
| **Windows** | Fleet-Maintained Apps | | ✅ | ✅ | ✅ | ✅ | ✅ |
| | Custom software (`.msi`) | | ✅ | ✅ | ✅ | ❌ | ❌ |
| | Custom software (`.exe`, `.ps1`) | | ✅ ² | ✅ | ✅ | ❌ | ❌ |
| **Linux** | Custom software (`.deb`, `.rpm`, `.sh`, `.tar.gz`) | | ✅ ² | ✅ | N/A | ❌ | ❌ |
| **iOS / iPadOS** | Apple App Store | VPP connection | ✅ ¹ | ✅ ³ | N/A | ✅ | ✅ |
| | Custom software (`.ipa`) | | ❌ | ❌ | N/A | ❌ | ❌ |
| **Android** | Google Play Store | | ❌ | ✅ | N/A | ❌ | ❌ |
¹ **Apple App Store auto-install (iOS / iPadOS / macOS)** is managed by Primo (not natively by Fleet). After enabling, install requests are pushed on the next device sync cycle.
² **Windows `.exe` / `.ps1` and Linux `.deb` / `.rpm` / `.sh` / `.tar.gz`** require a custom detection osquery. Primo pre-fills a best-effort query from the software name; the admin must verify and edit it before saving. See [How to find the right program name](./guides/find-program-name).
³ **Self-service on iOS / iPadOS** is reached from the portal's web URL, not from a desktop app. Add it to the Home Screen with the **Web Clips** control and its **Add the Self-Service web clip** option. See [App Store apps](./policies/app-store-apps).
Devices enrolled with user enrollment and a Managed Apple Account (BYOD) are not covered by the software installation journey, self-service included.
## Track what is installed
Once an app targets devices, follow its rollout from the **Software** tab of the device drawer, the count columns of the software table, or the **Devices** tab of the software page. See [Software installation status](/mdm/software-installation-status).
# Keyboard layouts & localization
Source: https://docs.getprimo.com/mdm/zero-touch/keyboard-layouts-localization
Understand how keyboard layout selection affects Zero-Touch Deployment (ZTD) eligibility when ordering devices.
## Select keyboard layout when ordering
When you order a device, the keyboard you select determines ZTD eligibility.
### Local keyboard (recommended)
Primo applies the standard keyboard for the delivery country and routes the order to a ZTD-authorized supplier.
Examples:
* France → AZERTY
* Belgium → QWERTY BE
* Germany → QWERTZ DE
* United Kingdom → QWERTY UK
* United States → QWERTY US
### Specific keyboard layout
Available options: QWERTY US, QWERTY UK, QWERTY International, QWERTZ, Spanish QWERTY, AZERTY.
Selecting a keyboard layout that is **not local to the delivery country disables Zero-Touch Deployment**.
## Check ZTD availability by delivery region and keyboard
| Delivery region | Local keyboard | ZTD available | Non-local keyboard | ZTD available |
| --------------- | ------------------------------------ | ------------- | ------------------------------ | ------------- |
| EU | AZERTY in France; local QWERTY in EU | Yes | QWERTY US / UK / International | No |
| UK | QWERTY UK | Yes | AZERTY / QWERTY US / QWERTZ | No |
| US | QWERTY US | Yes | AZERTY / QWERTY UK / QWERTZ | No |
## Common ordering scenarios
* **Delivery to the United States**
* Local keyboard → ZTD available
* QWERTY International or AZERTY → ZTD not available
* **Delivery to France (EU)**
* Local keyboard (AZERTY) → ZTD available
* QWERTY US or QWERTY International → ZTD not available
* **Delivery to France with a requirement for QWERTY US keyboards**
* ZTD is not available through Primo's standard ordering flow
## Frequently asked questions
### Why is ZTD unavailable with QWERTY International in France?
ZTD depends on supplier accreditations tied to specific regions. In France, only suppliers providing AZERTY keyboards are accredited for Apple ABM or Microsoft Autopilot. Selecting a non-local keyboard routes the order to a different supplier that is not authorized for ZTD in that region.
### Can I order devices in France with QWERTY US keyboards?
Yes. You have two options:
1. **Place a standard order without ZTD**: select QWERTY US. Suppliers deliver the devices ready to use, without Zero-Touch Deployment.
2. **Submit a special request (longer lead time)**: add a comment to your order requesting **"QWERTY US + ABM"**. Primo checks availability with suppliers. Expected lead time: **3 to 4 weeks**.
### Does selecting "AZERTY" always enable ZTD?
No. If you manually select AZERTY for a delivery **outside France**, ZTD is not available: a France-based, ZTD-authorized supplier cannot handle the order. To ensure ZTD eligibility, always select **Local keyboard** rather than a specific layout.
# Set up zero-touch deployment on your catalog
Source: https://docs.getprimo.com/mdm/zero-touch/setup-zero-touch-catalog
Configure Apple Business Manager and Microsoft Entra so Primo enrolls ordered devices automatically with zero-touch deployment.
This article explains how to configure Apple Business Manager (ABM) or Microsoft Entra so Primo enrolls ordered devices automatically on delivery with zero-touch deployment (ZTD).
## Understand why ZTD depends on local keyboards
Zero-touch deployment relies on supplier accreditations that are region-dependent:
* **Mac devices** enroll through **Apple Business Manager (ABM)**
* **Windows devices** enroll through **Microsoft Autopilot**
Only suppliers accredited in a given region can provide these services, and they can only deliver devices with the local keyboard configuration of that region.
If you select a non-local keyboard, Primo routes the order to a different supplier that is not accredited for ZTD, so zero-touch deployment is unavailable.
## Configure Apple Business Manager for ZTD
To enroll Apple devices ordered through Primo automatically in zero-touch, authorize the reseller to enroll devices in your ABM.
Go to **Orders & Shipments > Settings > Shipping countries**.
Next to the relevant country, click **Zero Touch Apple > To Setup > Zero-Touch Deployment for Macs > Enable**.
Select your existing **Organization ID** or create a new one. If you create one, use your company name followed by the ISO country code as the **Organization ID name** (for example, `Primo FR` when enabling zero-touch on the French catalog). Enter the ID shown in Apple Business Manager (**Devices > Inventory > Apple Customer Number**) as the **Organization ID**.
Open [Apple Business Manager](https://business.apple.com/) and click **Devices > Inventory > Customer Number > Add > Reseller Number**. Enter the Reseller number shown in the Primo cockpit.
Back in the cockpit, check **"I've added these Reseller IDs in Apple Business Manager"** to confirm the action, then click **Confirm** to finalize.
## Configure Microsoft Entra for ZTD
### Step 1: Authorize the reseller to register future devices
Go to [**Settings → Orders**](https://app.getprimo.com/settings/).
Under **Zero-Touch Procurement**, click **Windows**.
Select the country or countries where you want to enable Autopilot procurement, then click **Authorize our reseller**.
Complete the steps shown on screen.
A confirmation screen indicates that the partner relationship is created.
### Step 2: Enter Microsoft Entra information
Log in to the [Azure portal](https://portal.azure.com/) and search for **Microsoft Entra ID**.
Copy your **Tenant ID** and **Primary Domain**, then paste them into the cockpit.
Turn on the configuration toggle to finalize the integration.
# Zero Touch for Apple
Source: https://docs.getprimo.com/mdm/zero-touch/zero-touch-macs
Connect Apple Business to automatically enroll, preconfigure, and secure Apple devices purchased through authorized resellers.
As of April 14, 2026, Apple Business Manager is now known as **Apple Business**. References to "Apple Business Manager" or "ABM" in third-party documentation refer to the same service.
## Prerequisites
* **Device Manager or Administrator** access to an **Apple Business account** ([create one](https://business.apple.com/))
## Set up zero-touch deployment
Go to **MDM > Settings**, then select **Apple Business**. Download the public key from this page — you'll need it in the next step.
1. Head to [Apple Business](https://business.apple.com/), click your account name at the bottom left, and select **Preferences**.
2. Under **Device Management Services**, select **Add** and enter a name for the server such as "Primo".
3. Check the option **Allow this MDM server to release devices**.
4. In **MDM Server Settings**, upload the public key downloaded in the first step and select **Save**.
5. Select the newly created server from the sidebar, then select **Download Token** at the top.
Back in **MDM > Settings > Apple Business**, upload the `.p7m` token downloaded in the previous step.
1. Head to [Apple Business](https://business.apple.com/), click **Your Devices** and select **All Devices** at the top.
2. Under **Edit MDM Server**, select the new server and reassign all devices to it.
1. Head to [Apple Business](https://business.apple.com/), click your account name at the bottom left, and select **Preferences**.
2. Under **Your MDM Servers**, select **Default MDM Server Assignment** and click **Edit**.
3. Update all entries to the new MDM server, then click **Done**.
## Add devices to Apple Business
### 1. Purchase devices directly through Primo
Devices purchased through Primo are fully zero-touch compatible. [Learn more about ordering devices with zero-touch deployment.](/mdm/zero-touch/setup-zero-touch-catalog)
### 2. Purchase devices through an authorized B2B reseller
You can also purchase Apple devices through an authorized B2B reseller. In this case, make sure that:
* The reseller is **Apple-authorized**
* The reseller correctly assigns the devices to your **Apple Business account** at the time of purchase
Once assigned to Apple Business, the devices become available for enrollment and can be deployed using zero-touch deployment.
### 3. Add devices manually using Apple Configurator for Mac
You can manually add devices to Apple Business using **Apple Configurator**. The device must be erased and physically connected during the process. For detailed instructions, refer to Apple's official documentation: [Add devices to Apple Business Manager using Apple Configurator](https://support.apple.com/en-us/guide/apple-business-manager/axm200a54d59/web).
# Zero-touch for Windows
Source: https://docs.getprimo.com/mdm/zero-touch/zero-touch-windows
Windows Autopilot gives new Windows devices an out-of-the-box setup experience. When an employee powers on a device for the first time, they sign in with their Microsoft credentials, and Autopilot applies all company apps, settings, and security policies automatically — no IT intervention required.
## Prerequisites
* A Microsoft account with administrator access to an Entra tenant
* A license that includes **Microsoft Entra ID Plan 1** (or **Plan 2**) & **Windows Autopilot**
The minimum license covering both features is **Enterprise Mobility + Security E3** ([compare plans](https://www.microsoft.com/fr-fr/microsoft-365/enterprise-mobility-security/compare-plans-and-pricing)).
## Restrictions
Autopilot devices use **Entra accounts** rather than local accounts. Microsoft is progressively deprecating local accounts in favor of Entra accounts.
The Entra administrator can configure whether users have standard or administrator account privileges. Entra users with the **Global Administrator** role are automatically administrators on all Autopilot devices they sign into.
The device needs internet access during the first boot to authenticate with Entra.
## Set up zero-touch
This step requires coordination with Primo support. Microsoft generates a verification code — share it with the Primo team. Allow up to **2 business days** for us to validate the code after you send it.
1. Sign in to [Microsoft Azure](https://portal.azure.com/) with an administrator account.
2. Open [**Domain names**](https://portal.azure.com/#view/Microsoft_AAD_IAM/DomainsList.ReactView) and click **+ Add custom domain**.
3. Enter `{company}.mdm.getprimo.com`. [Contact support](mailto:support@getprimo.com) if you don't know your domain.
4. Share two values with the Primo team: the **Destination or routing address** (format: `MS=ms12345678`) and your **Tenant ID** (visible on the [Microsoft Entra overview page](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Overview)). Fleet needs the Tenant ID to authorize enrollment from your tenant.
5. Wait for our confirmation before clicking **Verify**.
1. Go to [**Mobility (MDM and MAM)**](https://portal.azure.com/#view/Microsoft_AAD_IAM/MdmAppsListBlade) and click **+ Add application > + Create your own application**. Enter `Primo` as the name and click **Create**.
2. Fill in the MDM URLs and click **Save**:
Replace `{company}` with your slug
```text theme={null}
https://{company}.mdm.getprimo.com/api/mdm/microsoft/tos
```
```text theme={null}
https://{company}.mdm.getprimo.com/api/mdm/microsoft/discovery
```
3. Open the **Fleet** application > **Custom MDM application settings** > click the link under **Application ID URI** > **Edit** > enter `https://{company}.mdm.getprimo.com` > **Save**.
4. On the same page, copy the **Application (client) ID** and share it with the Primo team. We register it on your Fleet instance, together with your Tenant ID, to complete the Windows enrollment configuration.
5. Go to **API permissions > Add a permission > Microsoft Graph > Delegated permissions** and add:
```text theme={null}
Group.Read.All
Group.ReadWrite.All
```
6. Add another permission under **Application permissions**:
```text theme={null}
Device.Read.All
Device.ReadWrite.All
Directory.Read.All
Group.Read.All
User.Read.All
```
7. Click **Grant admin consent for \{Your Company}**.
1. Go to [**Mobility (MDM and MAM)**](https://portal.azure.com/#view/Microsoft_AAD_IAM/MdmAppsListBlade).
2. Click **Microsoft Intune** > set **MDM user scope** and **MAM user scope** to `None` > **Save**.
3. Click **Fleet** > set **MDM user scope** and **MAM user scope** to `All` > **Save**.
If devices are already enrolled through Intune before this change, migrate them yourself — see [Migrate from another MDM](/mdm/rollout/silent-agent-deployment#migrate-from-another-mdm). Without it, those devices remain in an inconsistent state that degrades the user experience.
A deployment profile defines the default settings of devices that enroll through Autopilot, such as
* user account type (Administrator or Standard)
* default country and keyboard language
* device naming pattern (e.g. `{company}-%RAND:5%` → `{company}-23456`)
See [Microsoft's official documentation](https://learn.microsoft.com/fr-fr/autopilot/profiles) for full details.
1. **Create the profile** — go to [Intune admin center](https://intune.microsoft.com/#view/Microsoft_Intune_Enrollment/AutopilotDeploymentProfiles.ReactView) > **Devices > Enrollment > Deployment Profiles** > **+ Create profile** and complete the three steps: name, deployment mode, assignment.
2. **Create a dynamic device group** — go to [portal.azure.com](https://portal.azure.com/#view/Microsoft_AAD_IAM/GroupsManagementMenuBlade/~/Overview) > **+ Create group**, name it (e.g. "Windows Autopilot devices"), select `Dynamic devices`, and use the rule:
```text theme={null}
(device.devicePhysicalIds -any (_ -startsWith "[ZTDid]"))
```
3. **Create an Enrollment Status Page** — go to [Intune admin center](https://intune.microsoft.com/#view/Microsoft_Intune_Enrollment/EnrollmentStatusPageProfileList.ReactView) > **Devices > Enrollment > Enrollment Status Page** > **+ Create**, name the profile, enable progress display, and assign it to your dynamic group.
The logo uploaded here appears on the Autopilot sign-in screen next to a **Welcome to \{Your Company}!** title. It is also the quickest way to confirm that a device actually goes through Autopilot at first boot.
1. Sign in to [Microsoft Azure](https://portal.azure.com/), search for **Company branding**, then click **Configure** (or **Edit** if a default sign-in experience already exists).
2. Open the **Sign-in form** tab and upload your logo in both **Square logo (light theme)** and **Square logo (dark theme)**.
3. Click **Review + save**, then **Save**.
## Register your devices in Autopilot
A deployment profile only applies to devices **registered in Autopilot**. Registration is not enrollment. It links a device's hardware identity to your Entra tenant, so Windows recognizes the device at first boot and launches the Autopilot experience.
Our accredited resellers register devices ordered through Primo — nothing to do on your side. See [Device orders with Zero-Touch](/mdm/zero-touch/device-orders-zero-touch). The steps below only apply to devices acquired outside Primo.
On the device, open PowerShell as administrator and run:
```powershell theme={null}
New-Item -Type Directory -Path "C:\HWID"
Set-Location -Path "C:\HWID"
$env:Path += ";C:\Program Files\WindowsPowerShell\Scripts"
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo -OutputFile AutopilotHWID.csv
```
This generates a CSV file containing the hardware hash. [Microsoft's documentation](https://learn.microsoft.com/en-us/autopilot/add-devices#desktop-hash-export) covers other export methods.
1. Go to [Intune admin center](https://intune.microsoft.com/) > **Devices > Enrollment > Windows Autopilot > Devices**.
2. Click **Import** and upload the CSV. The import takes a few minutes — refresh the page until the device shows up.
3. Confirm the **Profile status** column reads `Assigned`. If it stays on `Not assigned`, review the assignment of your deployment profile (step 4 above).
## Test the enrollment
Validate the full flow on a single registered device before rolling out company-wide.
1. Reset the test device (**Settings > System > Recovery > Reset this PC**) or reimage it.
2. Power it on, select the country and keyboard layout, and connect to the internet.
3. Confirm the sign-in screen shows **Welcome to \{Your Company}!** with your logo — this proves the device went through Autopilot.
4. Sign in with a test employee's Entra credentials. Windows then asks to create a PIN (Windows Hello), plus a fingerprint if the hardware supports it.
5. Once the desktop loads, the device appears in the dashboard and receives the apps and policies defined there.
Devices that are **not** registered in Autopilot can still enroll automatically: during Windows setup, choose **Set up for work or school** and sign in with Entra credentials. The device enrolls in Fleet, but skips the branded Autopilot experience and the Enrollment Status Page.
## Reset or reassign a device
When a device changes hands — offboarding, replacement, repurposing — clean up its old records so it goes through Autopilot again like a brand-new device.
Trigger a remote wipe from the dashboard, or reset it locally via **Settings > System > Recovery > Reset this PC**.
Delete the device from the dashboard so the next enrollment starts from a clean record.
In [Microsoft Azure](https://portal.azure.com/), go to **Devices > All devices** and delete the stale object of the wiped device.
Never delete the device from **Windows Autopilot > Devices** — the registration must survive the wipe.
In [Intune admin center](https://intune.microsoft.com/) > **Devices > Enrollment > Windows Autopilot > Devices**, confirm the device is still registered with a **Profile status** of `Assigned`, then click **Sync** and wait for the sync to complete.
The branded welcome screen confirms Autopilot picked the device up. If the device skips Autopilot at first boot, wait a few minutes and restart it — the Autopilot service may still be processing the cleanup.
# Create and manage your catalog
Source: https://docs.getprimo.com/procurement/add-products-catalog
Primo uses per-country catalog management. Each country must be added individually in Orders & Shipments > Settings before you can order products for that country.
Primo manages product availability on a **per-country basis**. Before you can place orders for a given country, that country must be configured in your workspace settings.
## Add a country to your catalog
Each country you want to order from or ship to must be added individually:
1. Go to **Orders & Shipments > Settings**.
2. Click **Add country**.
3. Select the country from the list.
4. Configure any country-specific settings (e.g. preferred carrier, tax settings).
5. Save.
Repeat for each country where you have employees or want to source equipment.
Countries are managed independently — adding one country does not affect the catalog or settings of other countries.
## Request a missing product
If a product is available in your country but not yet listed in the Primo catalog:
1. Open the **Catalog** section in your cockpit.
2. Click **Add** in the top right corner.
3. Fill in the product details:
* Complete product name and model number
* Manufacturer information
* Technical specifications
* Country where the product should be available
4. Submit.
Our team will review your request and add the product to the appropriate country catalog.
# Create a shipment
Source: https://docs.getprimo.com/procurement/create-shipment
Generate a shipping label and create a return shipment in Primo — either from the offboarding flow or manually from the cockpit.
You can create a shipment in Primo to organize the return of equipment from an employee. There are two entry points: the offboarding flow (recommended) and a manual shipment from the cockpit.
## From the offboarding flow (recommended)
Use this method when offboarding an employee. The employee's address is pre-filled automatically.
1. Go to the employee's **Offboarding** page.
2. Navigate to the **Manage Equipment** step.
3. Enable the toggle **Create a shipping label**.
4. You are redirected to the shipment configuration page.
Continue with the [configuration steps below](#configure-the-shipment).
## From the cockpit (manual)
Use this method to create a shipment independently of an offboarding.
1. Go to **Purchasing > Shipments**.
2. Click **New**.
3. Select the device(s) and/or accessories to ship.
4. Click **Next**.
Continue with the [configuration steps below](#configure-the-shipment).
## Configure the shipment
The following steps apply to both entry points:
Choose where the package is being shipped from (typically the employee's address).
Choose the destination (typically your office or a warehouse address).
In **Shipment Notifications**, add the email address(es) that should receive the shipping label — for example, the employee, an HR admin, or a shared inbox.
Choose the billing profile that will be charged for the shipment cost.
Purchase a return box to be sent to the employee. The box comes with the shipping label so the employee can package and return the device easily.
Click **Validate** to confirm and generate the shipping label.
## After creating the shipment
* The shipping label is emailed to the address(es) specified in Shipment Notifications within 24 hours.
* The label is also available in **Purchasing > Shipments > Label**.
## Employee instructions
Share the following with the employee:
1. They will receive the shipping label by email within 24 hours.
2. If a return box was ordered, it will arrive separately.
3. They should package the device securely, apply the label, and hand it to the carrier.
## Related articles
* [Track a shipment](/procurement/track-shipment)
* [Customs & international shipments](/procurement/customs-international-shipments)
* [Automated offboardings](/employees/automated-offboardings)
# Customs & international shipments
Source: https://docs.getprimo.com/procurement/customs-international-shipments
Understand when customs duties and clearance apply to shipments between the EU, the United Kingdom, and the rest of the world.
## Customs fees and clearance for international shipments
Customs duties and clearance apply depending on whether a shipment crosses a customs border, not simply on whether it crosses a country border.
### Route & customs clearance
| Route | Customs / clearance |
| ---------------------------------------------------------------- | ------------------- |
| France to France (or EU to EU) | None |
| England to/from the European Union | Yes, both ways |
| International (outside the EU and UK) to/from the European Union | Yes, both ways |
### Why customs rules differ
Customs fees apply only when a package crosses a customs border, meaning the boundary of the European Union customs territory. Within the single market (for example France to Germany, or France to France), goods move freely, with no customs declaration and no duties to pay.
As soon as a shipment leaves or enters a country outside this customs territory (the United Kingdom since Brexit, the United States, Switzerland, and others), it must clear customs. Customs files a declaration, calculates customs duties and import VAT, and the carrier charges brokerage fees.
### Details by zone
#### 1. France to France (and more broadly EU to EU)
No customs fees, no clearance. The invoice includes standard domestic VAT, with no import step.
#### 2. England to/from the European Union
Since Brexit, the United Kingdom is no longer part of the EU customs territory. Every shipment between England and the EU, in both directions, therefore crosses a customs border.
**To the United Kingdom:** import VAT of 20% applies to all imports above £135. The United Kingdom uses its own customs tariff (UK Global Tariff), separate from the EU's. Goods originating in the EU generally enter at zero customs duty under the EU-UK trade agreement, provided you can show proof of origin.
**To the EU from the United Kingdom:** the carrier calculates customs duties based on the product's HS code and customs value, plus import VAT at the destination country's rate (20% in France), plus carrier handling fees.
#### 3. International (outside the EU and UK) to/from the European Union
Same logic: any shipment between the EU and a third country (United States, Switzerland, and others) requires customs duties and import VAT.
When the carrier reports additional fees, our operations team always contacts you to confirm the exact extra amount and to check whether you want to proceed with the shipment or cancel it.
## Related articles
* [Create a shipment](/procurement/create-shipment)
* [Track a shipment](/procurement/track-shipment)
# Equipment policy
Source: https://docs.getprimo.com/procurement/equipment-policy
An AI-powered policy that defines which devices and accessories your employees can order based on their profile, and curates the catalog automatically.
The Equipment Policy is an **AI-powered policy** that defines the equipment your employees are entitled to based on their profile. You write your rules in plain language — for example, *"Sales get a MacBook Air; Engineering get a MacBook Pro with at least 16 GB of RAM"* — and Primo resolves them into a curated selection. When you order for an employee or set up their onboarding, Primo surfaces a **From your Policy** section at the top of the catalog with the right hardware for their team, role, seniority, and location.
You maintain one set of rules. Primo keeps the matching products up to date for you: change a rule and republish, and the curated selection re-resolves across every country — so what you see first is always current and consistent, with no per-country lists to hand-maintain.
There is one Equipment Policy per company.
The Equipment Policy replaces catalog **favorites**. Instead of manually flagging products for each country, you describe your rules once and Primo keeps the curated selection in sync automatically.
Equipment Policy defines **what** equipment an employee is entitled to. It is separate from the Purchasing Policy, which defines **how** purchases are approved (budgets and spending limits).
## How it works
You describe your policy in plain language — Primo AI reads it and resolves it into a concrete list of catalog products. There are no rigid forms to fill in: you write the rules the way you would explain them to a colleague, and the assistant does the matching.
Describe who is entitled to what, in prose. Save to keep a draft.
Publishing resolves your policy against the catalog, per country.
The resolved products appear in the order flow and during onboarding, curated per employee.
## Set up your policy
Find the **Equipment Policy** card and click **Setup**.
Use the content editor to describe your rules in plain language. Cover:
* **Eligibility** — who gets what, by team, role, seniority, or location.
* **Devices** — which laptops and other devices each group can order.
* **Accessories** — which peripherals and accessories are covered.
* **Onboarding hardware** — the default equipment a new hire receives.
Changes save as a draft. Primo doesn't apply drafts until you publish.
### Write it with AI
You don't have to write the policy from scratch. The docked AI chat on the policy page can build it with you conversationally — describe your rules and it drafts the policy, or ask it to adjust what you already have. See [Primo AI](/ai/primo-ai).
You can also add or remove products directly from the catalog: on a product card, use the policy shortcut to tell the assistant to **add these devices to my equipment policy** or **remove these devices from my equipment policy**.
## Example rules
Write rules the way you'd explain them out loud. A policy can be as simple or as detailed as you need:
* *"Sales and Support get a MacBook Air 13". Engineering and Design get a MacBook Pro 14" with at least 16 GB of RAM."*
* *"Managers and above can add an external monitor and a docking station."*
* *"Everyone gets a keyboard, a mouse, and a headset during onboarding."*
* *"In the US, offer the QWERTY keyboard layout; in France, offer AZERTY."*
* *"Contractors get a standard laptop only — no accessories."*
Each of these shapes how Primo curates the catalog. You don't pick products country by country — you state the rule once, and the right products surface automatically wherever they apply.
## Use cases
A new engineer joins in Germany. Their onboarding automatically proposes a MacBook Pro with 16 GB of RAM and the standard accessory kit — no one has to remember the rule or look up which model ships to Germany.
When you order for an employee, Primo surfaces an **In policy for this employee** section matched to their profile — the right hardware is one click away instead of buried in the full catalog, with no rule to look up.
You upgrade the Engineering standard to 32 GB of RAM. Edit one sentence, republish, and every country's catalog and every future onboarding reflects it instantly.
A rule like "Design gets a MacBook Pro" resolves to the correct local model in each country you ship to, so teams get equivalent equipment everywhere.
## Publish your policy
Publishing applies the policy. When you publish, Primo resolves your prose into a concrete list of allowed products for each enabled shipping country. This runs in the background and can take a few minutes.
* Click **Publish** to apply a new or updated policy.
* Click **Unpublish** to stop applying it while keeping your draft.
Each country resolves independently. Until a country finishes, its curated catalog isn't available yet.
Because AI resolves the policy, results are not fully deterministic. Re-publishing the same rules can surface a slightly different set of products from one run to the next. After publishing, verify the curated selection per country and refine your rules if needed.
## Where your policy applies
Once published, the policy curates the catalog wherever employees choose equipment:
* **Ordering** — the order flow shows a **From your Policy** section with the products allowed for the selected country.
* **Per employee** — when ordering for a specific person or during onboarding, an **In policy for this employee** section shows the subset that matches that individual's profile.
If a country has no matching products, edit the policy to add options or switch country.
## Best practices
Describe eligibility the way you'd brief a colleague. The assistant interprets plain language.
Name the teams, roles, seniorities, or locations your rules apply to so products resolve correctly.
The policy resolves per country. Make sure your rules account for the models available in each.
After publishing, check the curated catalog per country and refine the policy as needed.
# Get started with Global Purchasing
Source: https://docs.getprimo.com/procurement/get-started
Everything you need to start ordering IT equipment through Primo — set up your catalog, configure billing profiles, and enable procurement in the countries you operate in.
Use the cards below to complete the three steps to get started with Primo's Global Purchasing.
Define which devices and accessories are available for your employees to order. Configure approved models, spending limits, and procurement policies.
Primo ships to 30+ countries. Review the list of supported countries and configure the ones where your employees are located.
Configure who gets invoiced for orders. You can set up multiple billing profiles for different entities, countries, or cost centers.
***
## What you can do with Global Purchasing
* Order laptops, smartphones, accessories, and more through Primo's B2B procurement network.
* Benefit from **Zero Touch Deployment** — devices arrive pre-enrolled and ready to use on first boot.
* Track orders, manage shipments, and handle returns directly from the cockpit.
* Manage warranties and extended AppleCare Enterprise coverage.
For questions about getting started, contact [support@getprimo.com](mailto:support@getprimo.com).
# Modify or cancel an order
Source: https://docs.getprimo.com/procurement/modify-or-cancel-order
Learn when you can cancel an order, why orders can't be modified once placed, and what happens if an ordered item is out of stock.
After you place an order, you may need to cancel it or change something on it. This article explains when you can cancel, why you can't modify a placed order, and what happens if an item becomes unavailable.
## How to cancel an order
You can only cancel an order while it is still in the **Placed** status. Once an order moves to **Fulfilled**, our operations team has already processed it and you can no longer cancel it. See [Order statuses](/procurement/track-your-order#order-statuses) for the full list of statuses and what each one means.
To cancel an order:
Open the **Orders & Shipments > Orders** section in the cockpit.
Select the order you want to cancel.
Click **Action > Cancel**.
Once an order reaches **Fulfilled** status, you can no longer cancel it from the cockpit. Contact [support@getprimo.com](mailto:support@getprimo.com) with questions about an order that has already been processed.
## How to modify an order
You can't modify a placed order directly — including the product, quantity, or shipping details. To change an order, cancel it while it's still in **Placed** status and place a new one with the correct information.
## Out-of-stock items
On rare occasions, our supplier runs out of an item you ordered before we process it. When this happens, our operations team contacts you directly and suggests a similar alternative product, so you don't have to wait for a restock. We work to keep your delivery on time for your new team member's start date.
## Contact
Our operations team is available for any question about your order. Reach out to [support@getprimo.com](mailto:support@getprimo.com).
## Related articles
* [Track your order](/procurement/track-your-order)
* [Damaged in transit](/procurement/damaged-parcel)
* [Create a shipment](/procurement/create-shipment)
# Open a new country
Source: https://docs.getprimo.com/procurement/open-new-country
Request procurement access for a new country where your employees are located. Learn what's needed to enable ordering and shipping in a new region.
If you need to order equipment for employees in a country not yet enabled on your account, request access from the dashboard.
## Check if the country is supported
Before opening a request, verify that the country is in the supported shipping network:
* See the full list of [delivery countries](/procurement/shipping-countries).
If the country is supported, follow the steps below to activate it.
## Request a new country
To enable procurement in a new country:
If the country is not listed, request it at [support@getprimo.com](mailto:support@getprimo.com). Otherwise, click **Activate country**, enter a postal address located in that country, then click **Save**.
Under **Settings > General > Billing**, configure country-specific settings (such as tax settings), then add a billing profile for the relevant country.
As soon as you request a country, its catalog becomes available in the **Catalog** tab and you can place an order directly.
## What happens after activation
Once a country is enabled:
* You can place orders with delivery addresses in that country.
* Local shipping carriers and lead times apply.
* The country appears in the shipping address selector when placing orders.
## Country-specific considerations
Some countries have:
* Longer lead times due to customs or import processes.
* Limited product availability (not all SKUs ship to all countries).
* Specific warranty conditions.
For questions about a specific country, contact [support@getprimo.com](mailto:support@getprimo.com).
## Request support for a country not yet covered
If the country you need is not in the supported shipping network, request coverage by contacting:
[support@getprimo.com](mailto:support@getprimo.com)
Include the country and any relevant context about expected demand. The Primo team reviews the request and confirms how quickly we can enable shipping there.
## Related articles
* [Delivery countries](/procurement/shipping-countries)
* [Why buy with Primo?](/procurement/why-buy-with-primo)
# Setup AppleCare for Enterprise
Source: https://docs.getprimo.com/procurement/setup-applecare-enterprise
Set up AppleCare Enterprise (ACE), activate your MSA ID, and add ACE to your Primo orders.
For Apple devices, you can add AppleCare Enterprise (ACE) for extended professional support. AppleCare Enterprise is Apple's professional warranty and support offering for business devices. It extends coverage and provides access to dedicated Apple enterprise support.
## Purchase AppleCare Enterprise
To purchase ACE warranties through Primo, you need an Apple Business Account and an Enrolment ID.
* Register at [enterprise.apple.com/directEnroll](https://enterprise.apple.com/directEnroll)
* Select **ACE**
* Fill in your company and purchasing contact information
* Agree to the terms and conditions
* Save your **Enrolment ID**: go to your cockpit, tab "Orders & shipments" > Settings > AppleCare Enterprise > Enable > add your Enrolment ID
Before you can place an order with ACE from the cockpit, you must complete at least one Apple order with ACE directly from your Apple Business Account. After Apple activates that first order, it creates a Master Service Agreement (MSA), which lets you keep adding devices to the contract.
When placing an order:
* Select the device you want to purchase
* In the "Customise your order" section, enable the "AppleCare Enterprise" toggle
* In the "Comments" field, add your MSA number
## Open a support case with AppleCare Enterprise
1. Access the [AppleCare Enterprise console](https://enterprise.apple.com/).
2. Go to **Agreement page** to access your company documents.
3. Open a support case:
* **Employee self-service:** share the ACE End User Support document with the employee, or have them call the ACE number with the company PIN code.
* **Admin-created case:** open a case directly in the AppleCare Enterprise console.
## Related articles
* [Repairs & warranty claims](/procurement/repairs-warranty-claims)
* [Track your order](/procurement/track-your-order)
* [Damaged in transit](/procurement/damaged-parcel)
# Delivery countries
Source: https://docs.getprimo.com/procurement/shipping-countries
Current shipping coverage and how to request additional countries.
## Overview
The Procurement module lets you order devices and accessories for your employees, delivered directly to their location. This article explains where Primo ships and what to expect during delivery.
## How delivery works
Hardware suppliers fulfill orders placed through Primo and ship them directly to the delivery address you specify (office, employee's home, or a third-party location).
A few things to know:
* Delivery timelines vary by country and device availability. The dashboard displays estimated lead times at the time of order.
* When you enable zero-touch deployment, suppliers apply the configuration before shipment so devices arrive ready to enroll.
* You receive tracking information once the carrier picks up the shipment.
## Supported countries
Primo currently ships devices to the following countries:
### NORAM
* Canada
* USA
### EMEA
* Austria
* Belgium
* Bosnia
* Bulgaria
* Croatia
* Czech Republic
* Denmark
* Estonia
* Finland
* France
* Germany
* Greece
* Hungary
* Ireland
* Italy
* Latvia
* Lithuania
* Luxembourg
* Netherlands
* Norway
* Poland
* Portugal
* Romania
* Serbia
* Slovakia
* Slovenia
* Spain
* Sweden
* Switzerland
* Turkey
* United Kingdom
### APAC
* Australia
* China
* Hong Kong
* Indonesia
* Malaysia
* New Zealand
* Philippines
* Singapore
### LATAM
* Chile
* Colombia
* Mexico
For more information on enabling a new country on your account, see [Open a new country](/procurement/open-new-country). For details on when returns are accepted and how to submit a request, see [Return & exchange conditions](/procurement/return-conditions).
# Track a shipment
Source: https://docs.getprimo.com/procurement/track-shipment
Follow the progress of equipment return shipments in Primo — understand shipment statuses and access carrier tracking.
Once a shipment is created, you can track its progress directly from the Primo cockpit.
## Access shipments
1. Go to **Purchasing > Shipments**.
2. Click on any shipment to view its details and current status.
## Shipment statuses
| Status | Meaning |
| -------------------- | ------------------------------------------------------------------------------------------------------------ |
| **Label created** | The shipping label has been generated and sent by email. The package has not yet been handed to the carrier. |
| **In transit** | The carrier has picked up the package and it is on its way. |
| **Out for delivery** | The package is with the local carrier for final delivery. |
| **Delivered** | The carrier has confirmed delivery at the destination. |
| **Exception** | There is an issue with the delivery (address problem, failed delivery attempt, customs hold). |
| **Return to sender** | The package could not be delivered and is being returned to the sender. |
## Track with the carrier
From any shipment in **Purchasing > Shipments**:
1. Open the shipment details.
2. Click the **carrier tracking link** to follow the parcel on the carrier's website.
Carrier tracking updates may take a few hours after the package is handed over.
## Shipment not moving
If a shipment has been in **Label created** status for more than 48 hours:
1. Confirm that the employee has handed the package to the carrier.
2. Check that the shipping label was received (resend from **Purchasing > Shipments > Label** if needed).
3. Contact [support@getprimo.com](mailto:support@getprimo.com) if the issue persists.
## Related articles
* [Create a shipment](/procurement/create-shipment)
* [Customs & international shipments](/procurement/customs-international-shipments)
* [Damaged in transit](/procurement/damaged-parcel)
# Track your order
Source: https://docs.getprimo.com/procurement/track-your-order
Understand order statuses in Primo and track the progress of your device and accessory orders from placement to delivery.
After you place an order, you can track its status directly from the cockpit. This article explains the different order statuses and what each one means.
## Access your orders
1. In the cockpit, go to **Orders & Shipments > Orders**.
2. Click any order to see its details, status history, and tracking information.
## Order statuses
| Status | Meaning |
| ------------- | -------------------------------------------------------------------------------------- |
| **Placed** | The order has been created but not yet submitted. |
| **Confirmed** | The order has been submitted and accepted by Primo. |
| **Shipped** | The order has left the warehouse and is in transit. Tracking information is available. |
| **Closed** | The carrier has confirmed delivery. |
| **Cancelled** | The order was cancelled before shipment. |
### Purchase delivery statuses
| Status | Meaning |
| ------------- | --------------------------------------------------------------- |
| **Pending** | The purchase has not yet been processed by our operations team. |
| **Fulfilled** | The purchase has been processed by our operations team. |
| **Shipped** | The purchase has been shipped by the wholesaler. |
| **Delivered** | The purchase has been delivered. |
## Track a shipped order
After an order reaches **Shipped** status:
1. Open the order in **Orders & Shipments > Orders**.
2. Click the **Tracking** link to follow the shipment with the carrier.
Tracking information is provided by the carrier and may take a few hours to update after the order ships.
## Lead times
Lead times vary by product and country. Typical lead times:
* **In-stock items:** 2-5 business days for delivery in Europe.
* **Built-to-order (Mac, premium laptops):** 5-15 business days depending on configuration and destination.
* **International orders:** may have longer lead times due to customs.
For questions about a specific order, contact [support@getprimo.com](mailto:support@getprimo.com) with your order number.
## Related articles
* [Damaged in transit](/procurement/damaged-parcel)
* [Repairs & warranty claims](/procurement/repairs-warranty-claims)
* [Create a shipment](/procurement/create-shipment)
# SaaS audit logs
Source: https://docs.getprimo.com/saas/audit-logs
Track all administrative actions taken in Identity & SaaS Management — including provisioning events, rule changes, and app connection updates.
This page is a placeholder. Full documentation for SaaS Audit Logs is coming soon.
The SaaS Audit Log records all administrative actions performed in the Identity & SaaS Management section of Primo, including:
* App connection and disconnection events
* Provisioning and deprovisioning actions
* Rule changes (provisioning rules)
* Identity mapping updates
* Cost and contract modifications
## Access the audit log
1. Go to **SaaS > Audit Logs**.
2. Filter by date range, action type, or administrator.
3. Export to CSV for compliance reporting.
For questions about audit log retention, contact [support@getprimo.com](mailto:support@getprimo.com).
# Configure SSO with Primo as the identity provider
Source: https://docs.getprimo.com/saas/configure-sso
Configure Single Sign-On (SSO) with Primo as the identity provider by retrieving the necessary SSO details and entering your service provider's information to enable user authentication for third-party applications.
You can configure Single Sign-On (SSO) between Primo and an external service provider using Primo as the identity provider. This allows your users to authenticate through Primo when accessing third-party applications.
This article describes how to retrieve the necessary SSO information from Primo and complete the setup with your service provider.
## Choose Primo as the identity provider
1. Sign in to the Primo console.
2. Go to **Identities & Access > Apps catalog**.
3. In the list of login providers, select **Login with Primo, Google or Entra**.
## Retrieve configuration details from Primo
Provide the following SSO details to your service provider as required (depending on your Service Provider), for example:
### 1. Identity provider ID
Click **Copy identity provider ID** to copy the identifier needed by some service providers.
### 2. Metadata
* Click **Copy metadata URL** or **Copy metadata** to retrieve the full metadata.
* Provide this to your service provider to establish trust with Primo.
### 3. Login URL
Click **Copy login URL** if required by the service provider for the SSO redirection.
### 4. Certificates
* Click **Copy certificate** or **Download certificate** to get the public certificate.
* Use **Copy certificate SHA256** if your service provider requires a fingerprint for verification.
## Enter service provider information
After configuring the service provider with Primo's SSO information, enter the following details:
1. **Service provider entity ID**: Paste the entity ID provided by your service provider.
2. **Assertion consumer service (ACS) URL**: Enter the ACS URL used by your service provider to receive SAML assertions.
Click **Connect** to finalize the integration.
# Connect your apps
Source: https://docs.getprimo.com/saas/connect-apps
Connect your applications for secure, centralized access management, following the outlined steps to configure Single Sign-On (SSO), SCIM provisioning, or API-based integrations effectively.
The SaaS Management solution enables your organization to manage access to business applications in a secure and centralized way. By connecting your applications, you ensure that users are provisioned automatically, authentication is unified, and access rights are applied consistently across your tools.
This article explains the steps required to connect an application.
## Automated SaaS mapping
If you are using Google Workspace, you can connect it in Identities & Access. It will automatically map all the applications for which your Google Workspace is used as a SSO connector.
Once it's connected you can see all the identities related to each app and define a specific owner.
## Access the Apps catalog
1. Sign in to the Primo cockpit.
2. From the navigation menu, go to **SaaS**.
3. Select **Identities** and **Add a SaaS**
The [Apps catalog](https://app.getprimo.com/saas-applications/add-app) contains a list of applications that can be directly integrated.
## Select and configure the application
1. Locate the application you want to connect.
2. Click on the application to open its configuration page.
3. Follow the step-by-step instructions provided.
The configuration steps vary depending on the type of application:
* **Single Sign-On (SSO)**: You may need to provide metadata or certificates to establish trust with the application.
* **SCIM provisioning**: You may need to enter API credentials to allow automatic user account creation and updates.
* **API-based integrations**: Some applications require you to generate and input API keys.
On-screen guidance is provided for each application to complete the setup.
## Conclusion
You can click on the Logs tab and verify the sync is active.
If you think your plan is insufficient to configure your app, you can use the AI-based connection.
# Connected SaaS and properties
Source: https://docs.getprimo.com/saas/connected-saas-properties
Explore the various connected SaaS applications available, detailing their required plans, user provisioning, group and roles management, license management, and the necessity of single sign-on (SSO) for efficient integration and management.
## Connected apps overview
| Apps | Plan needed | User Provisioning | Groups management | Roles management | Licenses management | Other properties | SSO mandatory |
| ---------------- | -------------------------------- | ----------------- | ----------------- | ---------------- | ------------------- | ----------------------------- | ------------- |
| Notion | Enterprise | ✅ | ✅ | | | | |
| Slack | Business+ / Enterprise+ | ✅ | ✅ | | | | |
| Google Workspace | | ✅ | ✅ | ✅ | ✅ | Organizations unit management | |
| Hubspot | | ✅ | ✅ | ✅ | | | |
| AWS | | ✅ | ✅ | | | | |
| Entra | | ✅ | ✅ | ✅ | ✅ | | |
| Dropbox | | ✅ | | | | | |
| Asana | Enterprise / Enterprise + | ✅ | | | | | |
| Front | | ✅ | ❌ | | | | |
| 1Password | Business | ✅ | ✅ | | | | |
| Aircall | | ✅ | | | | | |
| Bitwarden | | ✅ | | | | | |
| Adobe | | ✅ | | | | | |
| Amplitude | Enterprise | ✅ | | | | | |
| Atlassian | | ✅ | | | | | |
| Box | | ✅ | ✅ | | | | |
| Dashlane | Business / Omnix | ✅ | ✅ | | | | |
| Datadog | Pro / Enterprise | ✅ | | | | | |
| Docusign | | ✅ | | | | | |
| Figma | Organization / Enterprise | ✅ | | | | | ✅ |
| GitHub | Enterprise | ✅ | ✅ | | | | ✅ |
| GitLab | Premium / Ultimate | ✅ | | | | | ✅ |
| Intercom | Expert | ✅ | | | | | ✅ |
| JetBrains | | ✅ | | | ✅ | | |
| Jira | | ✅ | | | | | |
| LastPass | | ✅ | ✅ | | | | |
| Linear | Enterprise | ✅ | | | | | |
| Metabase | Pro / Enterprise | ✅ | | | | | |
| Okta | | ✅ | ✅ | | | | |
| Zapier | Enterprise | ✅ | | | | | |
| Zendesk | | ✅ | | | | | |
| Zoom | Business | ✅ | | | | | |
| Airtable | Business / Enterprise | ✅ | | | | | ✅ |
| Cloudflare | | ✅ | | | | | |
| Monday | | ✅ | | | | | |
| Freshdesk | | ✅ | | ✅ | | | |
| Teamtailor | | ✅ | | | | | |
| Tableau | | ✅ | | | | | ✅ |
| Klaviyo | | ✅ | | ✅ | | | ✅ |
| Salesforce | | ✅ | | ✅ | | | |
| SendGrid | Pro / Premier | ✅ | | | | | |
| Make | | ✅ | ✅ | ✅ | | | |
| N8N | | ✅ | | | | | |
| Pipedrive | | ✅ | | | | | |
| Brevo | | ✅ | | | | | |
| Miro | Enterprise | ✅ | | | | | |
| Odoo | Custom | ✅ | | | | | |
| Ringover | | ✅ | | | | | |
| Tailscale | Enterprise | ✅ | | | | | |
| Segment | Business | ✅ | | | | | |
| Chili Pepper | | ✅ | | | | | |
| Canva | Enterprise / Canva for Districts | ✅ | | | | | |
| Shopify | Shopify Plus | ✅ | ✅ | | | | |
| PostHog | | ✅ | | | | | |
| Doit | | ✅ | | | | | |
# Cost management
Source: https://docs.getprimo.com/saas/cost-management
Track and optimize your SaaS spending in Primo — monitor licence costs, identify unused seats, and reduce waste across your software stack.
This page is a placeholder. Full documentation for Cost Management is coming soon.
Cost Management gives you visibility into what you're spending on SaaS, licence by licence, and helps you identify opportunities to reduce waste.
## What Cost Management covers
* **Licence tracking** — see the cost per seat for each connected application.
* **Usage analysis** — identify licences assigned to inactive or offboarded users.
* **Unused seat detection** — surface licences that haven't been used recently.
* **Renewal alerts** — receive notifications before SaaS contracts renew.
## Set up cost tracking
1. Go to **SaaS > Directory**.
2. Open a connected application.
3. Enter the contract details: cost per seat, billing cycle, renewal date.
Once costs are entered, Primo calculates your total SaaS spend and highlights optimization opportunities.
For help with cost tracking or bulk contract import, contact [support@getprimo.com](mailto:support@getprimo.com).
# Activate SaaS Discovery
Source: https://docs.getprimo.com/saas/get-started/activate-saas-discovery
Discover all SaaS applications used across your organization by activating SaaS Mapping via Google Workspace or the Primo Chrome Extension.
SaaS Discovery gives you a complete map of the applications used in your company — which apps, by which users, and with which identities. It helps you identify shadow IT, detect unused licences, and get full visibility into your SaaS stack.
Primo supports two discovery methods:
| Method | Coverage | Requirements |
| -------------------- | ----------------------------------- | -------------------------- |
| **Google Workspace** | Apps accessed via Google sign-in | Google Workspace connected |
| **Chrome Extension** | All apps accessed with a work email | MDM deployed via Primo |
SaaS Discovery via Microsoft Entra is not yet available.
***
## Activate via Google Workspace
If Google Workspace is connected, SaaS Mapping is enabled automatically. Primo maps every application for which your Google Workspace is used as a sign-in provider.
1. Connect Google Workspace if you haven't already — see [Connect your email provider](/saas/get-started/connect-email-provider).
2. Go to **SaaS > Directory** to see discovered applications.
No additional configuration is required. Discovery runs continuously in the background.
**What is captured:**
* The list of SaaS apps accessed using Google sign-in with a work account
* The associated work identity (user email) for each app
* No message content, files, passwords, or browsing history
***
## Activate via Chrome extension
The Chrome Extension extends SaaS Discovery beyond Google sign-in to capture any SaaS application accessed with a work email address — regardless of the login method.
### Requirements
* MDM deployed via Primo (the extension is deployed via MDM profiles)
* Google Workspace connected (required for the SaaS Management subscription)
* An active SaaS Management subscription
### Deploy the Chrome extension
In the Primo cockpit, navigate to **Devices > Profiles**.
Choose the profile applied to the devices where you want to deploy the extension.
Open the **Chrome** card and activate the extension toggle.
Choose which device groups should receive the extension.
The extension is pushed silently to targeted devices. Allow a few minutes for deployment.
### What the extension captures
* SaaS applications accessed with the professional email address
* The associated work identity for each app
**The extension does not capture:**
* Personal Chrome profiles or personal email activity
* Passwords, message content, or browsing unrelated to work
* Any activity outside the managed Chrome profile
### Verify discovery is working
1. Go to **SaaS > Directory** in the Primo cockpit.
2. Check that applications and identities appear for recent activity.
3. Use device group filters to review targeted rollouts.
***
## Troubleshoot SaaS Discovery
### No apps appear after activation
* Confirm Google Workspace is connected and the SaaS Management subscription is active.
* For the Chrome Extension, verify that the target devices are included in the profile and that the Chrome card is enabled.
### The extension isn't installing
* Check that the device is included in the targeted device group.
* Allow a few minutes for Chrome policy sync to complete.
### A user has multiple Chrome profiles
Only the managed Chrome profile you targeted is in scope. Ask the user to switch to their managed work profile.
***
## Related articles
* [Connect your email provider](/saas/get-started/connect-email-provider)
* [Add a SaaS from catalog](/saas/connect-apps)
* [Track a manual SaaS](/saas/manage-tracked-apps)
# Connect your email provider
Source: https://docs.getprimo.com/saas/get-started/connect-email-provider
Connect Google Workspace or Microsoft Entra ID to Primo to enable SaaS discovery, automated provisioning, and identity management across your organization.
Connecting your email provider is the first step to unlocking SaaS Management in Primo. It enables automatic user provisioning, SaaS discovery, and — when combined with offboarding — automated access revocation.
Primo supports two email providers:
Connect your Google Workspace organization to enable SaaS discovery, identity sync, and automated provisioning.
Connect your Microsoft Entra ID (formerly Azure AD) tenant to enable identity sync and automated provisioning.
***
## Google Workspace
### What connecting Google Workspace enables
* **SaaS Discovery** — automatically detect all apps accessed using Google sign-in across your organization.
* **Identity sync** — import your users and groups from Google Workspace.
* **Automated provisioning** — create, update, and suspend Google Workspace accounts as part of onboarding/offboarding workflows.
* **Data transfer at offboarding** — transfer Drive files and email ownership when an employee leaves.
### Connect Google Workspace
Navigate to **Settings > Integrations** and select **Google Workspace**.
You must authenticate as a Super Administrator to grant the required permissions.
Primo requests read access to users, groups, and org units — and write access for provisioning and offboarding actions.
Once connected, Primo imports your users and groups. SaaS Mapping begins automatically.
### What Primo accesses in Google Workspace
| Data | Purpose |
| --------------------------- | ------------------------------ |
| Users (name, email, status) | Identity sync and provisioning |
| Groups and org units | Apply provisioning rules |
| OAuth app access | SaaS Discovery mapping |
| Drive (at offboarding only) | File ownership transfer |
***
## Microsoft Entra ID
### What connecting Entra ID enables
* **Identity sync** — import users and groups from your Entra tenant.
* **Automated provisioning** — create, update, and disable Entra accounts as part of onboarding/offboarding.
* **Mac login via Entra** — allow employees to log in to their Mac with their Entra credentials (see [Entra Platform SSO](/mdm/policies/mac-login-entra)).
SaaS Discovery via Entra is not yet available. Use the Chrome Extension for broader SaaS coverage. See [Activate SaaS Discovery](/saas/get-started/activate-saas-discovery).
### Connect Microsoft Entra ID
Navigate to **Settings > Integrations** and select **Microsoft Entra ID**.
You need Global Admin or a delegated admin role with the required API permissions.
Primo requests permissions to read and write users, groups, and directory data.
Once authorized, Primo imports your users and groups from the Entra tenant.
### What Primo accesses in Entra ID
| Data | Purpose |
| --------------------------------------- | ------------------------------ |
| Users (name, email, status, attributes) | Identity sync and provisioning |
| Groups | Apply provisioning rules |
| Application assignments | SaaS visibility |
***
## Related articles
* [Activate SaaS Discovery](/saas/get-started/activate-saas-discovery)
* [Automate your onboardings](/employees/automate-onboardings)
* [Automated offboardings](/employees/automated-offboardings)
* [Entra Platform SSO for Mac](/mdm/policies/mac-login-entra)
# Identities
Source: https://docs.getprimo.com/saas/identities
View and manage all employee identities and their SaaS application access from one place in Primo.
This page is a placeholder. Full documentation for Identities is coming soon.
The Identities section gives you a unified view of every employee's digital identity — which applications they have access to, which accounts are active or suspended, and where access may be excessive or outdated.
## What you can do in Identities
* **View all identities** — see every user account associated with your connected SaaS apps, grouped by employee.
* **Detect orphaned accounts** — identify SaaS accounts that are no longer linked to an active employee.
* **Review access history** — see when an identity was last active in each application.
* **Map shadow IT** — identify applications used with a work email that aren't in your official SaaS catalog.
## Access the Identities view
1. Go to **SaaS > Identities**.
2. Filter by application, employee, or status.
For questions about identity management, contact [support@getprimo.com](mailto:support@getprimo.com).
# Set up licence provisioning
Source: https://docs.getprimo.com/saas/licence-provisioning
Set up provisioning to automate user account creation and updates in applications like Zendesk, ensuring employees have appropriate access roles based on defined rules without manual management.
Provisioning ensures that user accounts are automatically created and updated in connected applications according to the rules you define. By configuring provisioning, you can assign specific applications and roles to targeted groups of employees.
This article explains how to set up provisioning using Rules.
## Access rules
1. In the Primo console, go to **Identities & access**.
2. Select **Rules**.
3. Either **update an existing rule** or **create a new one** to manage provisioning rules.
## Create new rules (optional)
If you need to target a new group of employees, create a dedicated rule:
1. Click **Create a new rule**.
2. Enter a name for the rule (e.g., *Dev Team*).
3. Define the targeting conditions under **Targeted employees** (for example: *Team is Development*).
4. Save your rule.
## Enable provisioning for an application
1. Open the rule you want to use.
2. Go to the **Apps** tab.
3. Select the application you have already connected (e.g., Zendesk).
4. Toggle **Provisioning** to enable it.
5. Under **Roles selection**, choose the role you want to assign to the targeted employees.
For example, to assign the *Light agent* role in Zendesk to your development team:
* Create or edit the *Dev Team* rule.
* Define targeting: *Team is Development*.
* Select **Apps > Zendesk**.
* Enable **Provisioning** and assign the role *Light agent*.
## Result
Once provisioning is enabled and saved:
* Users matching the rule's targeting conditions are automatically created in the application if they are not already present.
* Assigned roles (e.g., Zendesk *Light agent*) are applied automatically.
* Any changes to users in the HR system will be synchronized with the application through Primo.
This ensures that employees always have the right level of access without manual account management.
# Manage tracked applications
Source: https://docs.getprimo.com/saas/manage-tracked-apps
Tracked applications allow for manual recording and monitoring of employee accounts, with designated owners responsible for managing account changes during onboarding or offboarding processes, ensuring centralized and updated tracking of account information.
Tracked applications are SaaS applications not connected for provisioning. Connecting them allows administrators to manually record and monitor employee accounts. This ensures complete visibility and centralized tracking of account information for each account, even when the SaaS cannot be provisioned.
## Assign an owner to a tracked application
* Each tracked application can have an **owner**.
* The owner is usually the person with an administrator account on this connected app.
* The owner is responsible for completing account-related tasks.
## Request account changes in tracked applications
Only administrators can request account changes for tracked applications.
These requests can be initiated in two ways:
* During an employee's **onboarding or offboarding process**
* Directly from the **employee's profile**
Once a request is submitted:
1. Primo notifies the application's owner.
2. The owner receives a **task** to complete (create, modify, or delete the account in the connected app).
3. After completing the action in the connected app, the owner confirms the task.
4. The confirmation updates the account information, keeping the tracking up to date.
### How tasks are grouped
When provisioning or deprovisioning multiple applications for the same employee (for example, during onboarding or offboarding), related tasks are grouped into a single ticket:
* **Single application**: A ticket is created with a title like "Create account for John Doe on Slack".
* **Multiple applications**: A ticket is created with a title like "Create accounts for John Doe", containing multiple tasks — one per application.
This grouping reduces notification noise and helps application owners manage related tasks efficiently.
### Types of tasks available
Tasks can be created to track the following actions:
* **Create** an account
* **Modify** an account
* **Delete** an account
# SaaS settings
Source: https://docs.getprimo.com/saas/settings
Configure your Identity & SaaS Management settings in Primo — manage integrations, provisioning defaults, and notification preferences.
This page is a placeholder. Full documentation for SaaS Settings is coming soon.
The SaaS Settings section allows administrators to configure the core behavior of the Identity & SaaS Management module.
## Available settings
* **Integrations** — manage connected email providers (Google Workspace, Entra ID) and other identity sources.
* **Provisioning defaults** — configure default behaviors for automated account creation and access revocation.
* **SaaS Discovery** — manage the Chrome Extension deployment and Google Workspace mapping scope.
* **Notifications** — set up alerts for licence renewals, orphaned accounts, and provisioning failures.
For help configuring SaaS settings, contact [support@getprimo.com](mailto:support@getprimo.com).
# Slack for ticketing
Source: https://docs.getprimo.com/tickets/slack
Connect your Slack workspace to create tickets from Slack and keep a ticket and its Slack thread in sync.
Connect Slack to work tickets where your team already talks. Once connected, your team creates tickets from Slack, and every ticket stays linked to its Slack thread so the conversation flows both ways.
## Connect your Slack workspace
Connecting Slack is an admin action. You do it once per workspace.
Go to **Tickets → Settings → Slack**.
Click **Connect Slack**. Slack opens so you can authorize the Primo app.
Approve the requested permissions in Slack. Slack returns you to ticket
settings, which now shows the workspace as connected.
If your workspace was connected before channel subscriptions existed, the
connection can't read channel messages. Open **Tickets → Settings → Slack**
and click **Reconnect Slack** to grant the missing access.
## Subscribe channels
After connecting, choose which channels feed ticketing under **Tickets → Settings → Slack**. Add each channel you want Primo to watch.
In a subscribed channel, a new message or an `@Primo` mention creates a ticket. Channels you don't subscribe are ignored.
## Create a ticket from Slack
You can open a ticket from Slack in three ways:
| From | How | Result |
| -------------------- | -------------------------------------------------------------- | ---------------------------------------- |
| A subscribed channel | Post a message, or `@Primo` mention the app | Primo creates a ticket from the message |
| Any message | Use the **Create ticket** message shortcut, then fill the form | Primo creates a ticket from that message |
| A slash command | Type `/primo ticket ` | Primo creates a ticket with that title |
Primo replies in the thread to confirm the ticket. That reply anchors the link between the ticket and the Slack thread.
Primo writes a title and description from the Slack message so the ticket is
ready to work without extra editing.
## Keep the conversation in sync
A ticket created from Slack stays linked to its thread, and the conversation syncs both ways:
* **Slack → ticket** — a reply in the linked thread becomes a comment on the ticket.
* **Ticket → Slack** — when you send a public reply from the ticket with **Also send to Slack** selected, Primo posts it back to the thread.
Internal notes are never sent to Slack. Only public replies reach the thread,
so internal context stays with your team.
Replies sync only inside a thread already linked to a ticket. A new message in the channel starts its own ticket rather than joining an existing one.
## Who messages come from
Primo attributes each Slack message to the right person:
* If a Slack user's email matches an **employee**, Primo records the message as that employee.
* If no employee matches, Primo records the message as an external requester by email.
* Messages posted by other apps or bots keep their Slack display name.
## Permissions
* **Connecting Slack and managing channel subscriptions** are admin actions in ticket settings.
* **Creating a ticket or replying from Slack** is available to anyone who can post in a subscribed channel or thread.
## Disconnect Slack
To stop the integration, go to **Tickets → Settings → Slack** and click **Disconnect**. Primo keeps existing tickets; no new tickets or replies come from Slack until you reconnect.
# Get all admins
Source: https://docs.getprimo.com/api-reference/admins/get-all-admins
https://api.getprimo.com/openapi.json get /admins
Return the list of admin users for your company. Each entry is either an employee (with an id) or an external user (identified by email only).
Key: ReadScope: Company
# Get the authenticated company
Source: https://docs.getprimo.com/api-reference/company/get-the-authenticated-company
https://api.getprimo.com/openapi.json get /company
Return the company associated with the API key. Only accessible with a Company API key.
Key: ReadScope: Company
# Archive a custom field
Source: https://docs.getprimo.com/api-reference/customfields/archive-a-custom-field
https://api.getprimo.com/openapi.json post /custom-fields/{customFieldId}/archive
Archive a custom field definition. Archived fields are no longer offered for new values but remain readable. Returns 409 if the field has active consumers (related entities must be cleared first).
Key: WriteScope: Company
# Create a custom field
Source: https://docs.getprimo.com/api-reference/customfields/create-a-custom-field
https://api.getprimo.com/openapi.json post /custom-fields
Create a new custom field definition. Labels are not constrained to be unique. Options are only allowed for SELECT and MULTI_SELECT field types.
Key: WriteScope: Company
# Get a custom field by ID
Source: https://docs.getprimo.com/api-reference/customfields/get-a-custom-field-by-id
https://api.getprimo.com/openapi.json get /custom-fields/{customFieldId}
Return the custom field definition for the given custom field ID — the definition only, not the values stored on entities. To read or write values, use the per-entity endpoints (`getDeviceCustomFields`, `getAccessoryCustomFields`, …).
Key: ReadScope: Company
# List custom fields
Source: https://docs.getprimo.com/api-reference/customfields/list-custom-fields
https://api.getprimo.com/openapi.json get /custom-fields
Return a paginated list of custom field definitions for your company — definitions only, without the values stored on entities. To read or write the values on a specific entity, use `getDeviceCustomFields`/`getDevicesCustomFields` (devices) or `getAccessoryCustomFields` (accessories). Defaults to ACTIVE fields when no status filter is supplied. A custom field definition can apply to one or more entity types — device, order, employee, or accessory — via its `applyTo` field.
Key: ReadScope: Company
# Update a custom field
Source: https://docs.getprimo.com/api-reference/customfields/update-a-custom-field
https://api.getprimo.com/openapi.json patch /custom-fields/{customFieldId}
Update label, applyTo (widen-only), optionsToAdd, or optionsToRename on a custom field. At least one field must be provided. Archived fields cannot be updated.
Key: WriteScope: Company
# Check a device group target before creating the group
Source: https://docs.getprimo.com/api-reference/devicegroups/check-a-device-group-target-before-creating-the-group
https://api.getprimo.com/openapi.json post /device-groups/validate-target
Validate a device group `target` without persisting anything: it reports whether the target is well-formed, whether every criterion is device-group-targetable (build it from `getDeviceGroupFiltersOptions`), and how many devices it currently matches — so a target that is valid but matches nothing is caught before the group exists. It returns counts and reasons, never device objects: to see WHICH devices match a filter, use `getDevices`.
Key: ReadScope: Company
# Create a device group
Source: https://docs.getprimo.com/api-reference/devicegroups/create-a-device-group
https://api.getprimo.com/openapi.json post /device-groups
Create a device group with a `name` and a `target` filter. `name` must be unique per company — always `GET /device-groups` first to list existing groups and avoid a duplicate (a conflicting name is rejected with 409). Check the target with `validateDeviceGroupTarget` (`POST /device-groups/validate-target`) to confirm it is targetable and matches the intended number of devices before creating. Build the `target` from the `GET /device-groups/filters-options` catalog; an invalid `target` is rejected with 400.
Key: WriteScope: Company
# Delete a device group
Source: https://docs.getprimo.com/api-reference/devicegroups/delete-a-device-group
https://api.getprimo.com/openapi.json delete /device-groups/{deviceGroupId}
Delete a device group by ID. A group that is still targeted by an MDM control or a software is rejected with 409 — call `GET /device-groups/:deviceGroupId/relations` to see what references it and remove those first. An unknown ID returns 404; deleting an already-deleted group is a no-op that still returns success.
Key: WriteScope: Company
# Get a device group by ID
Source: https://docs.getprimo.com/api-reference/devicegroups/get-a-device-group-by-id
https://api.getprimo.com/openapi.json get /device-groups/{deviceGroupId}
Return the device group: its `target` filter (the same shape create/update accept) plus the device IDs that filter currently resolves to. Read the `target` here before a PUT to change one field while preserving the rest of the targeting.
Key: ReadScope: Company
# Get all device groups
Source: https://docs.getprimo.com/api-reference/devicegroups/get-all-device-groups
https://api.getprimo.com/openapi.json get /device-groups
Return the list of device groups for your company (id, name).
Key: ReadScope: Company
# Get the device group filter catalog
Source: https://docs.getprimo.com/api-reference/devicegroups/get-the-device-group-filter-catalog
https://api.getprimo.com/openapi.json get /device-groups/filters-options
Return every criterion (native device attributes plus custom fields) that may target a device group, with its live company values inline. Use this to build a valid device-group target. This is a deliberately narrower set than the device **search** catalog (`getDeviceFilterCatalog`): a group targeting a volatile criterion would change population daily, and every MDM control targeting that group with it. To search the inventory instead of targeting a group, use `getDeviceFilterCatalog` + `getDevices`.
Key: ReadScope: Company
# Get what uses a device group
Source: https://docs.getprimo.com/api-reference/devicegroups/get-what-uses-a-device-group
https://api.getprimo.com/openapi.json get /device-groups/{deviceGroupId}/relations
List the softwares and MDM controls that target this device group. A group can only be deleted once both lists are empty — call this before DELETE to discover (and then remove) what still references it, or to explain a 409.
Key: ReadScope: Company
# Update a device group
Source: https://docs.getprimo.com/api-reference/devicegroups/update-a-device-group
https://api.getprimo.com/openapi.json put /device-groups/{deviceGroupId}
Replace a device group's `name` and `target` filter. Both fields are required — send the full desired state, not a partial patch. `name` must be unique per company (a conflicting name is rejected with 409). Build the `target` from the `GET /device-groups/filters-options` catalog and check it with `validateDeviceGroupTarget` (`POST /device-groups/validate-target`) before updating; an invalid `target` is rejected with 400.
Key: WriteScope: Company
# Ask a device to report its state back to the MDM
Source: https://docs.getprimo.com/api-reference/devices/ask-a-device-to-report-its-state-back-to-the-mdm
https://api.getprimo.com/openapi.json post /devices/{deviceId}/refetch
Ask ONE device to re-report its details, software inventory and policy results to the MDM. This refreshes what the MDM knows about the device, NOT Primo's own device record: the MDM only flags the device, the report lands the next time it checks in, and Primo picks that state up later through its own device sync. Use it after a fix (a script run, an install) before re-reading `getDeviceSoftware`, which otherwise still answers with the state captured by the last inventory cycle. Safe to call repeatedly. To re-read the Primo-managed software rows from the MDM instead of asking the device, use `syncDeviceSoftware`; to pull what the MDM already knows into Primo's own device record, use `syncPrimoDevice`.
Key: WriteScope: Company
# Cancel a queued activity on a device
Source: https://docs.getprimo.com/api-reference/devices/cancel-a-queued-activity-on-a-device
https://api.getprimo.com/openapi.json delete /devices/{deviceId}/activities/upcoming/{activityUuid}
Cancel ONE activity still queued on a device — a pending software install or uninstall, or a queued script — identified by the `uuid` returned by `getDeviceUpcomingActivities`. Use this to clear an install that is wedged (a package install Fleet leaves `in_progress` for up to an hour after the device went offline) and unblock the activities queued behind it. This does not undo work already done on the device: an activity that already started or finished cannot be cancelled and returns a 404. Cancelling is visible to the person waiting on that install, so confirm with the user before calling it. The software row keeps its `in_progress` state until the device state is resynced, so call `syncDeviceSoftware` afterwards before re-reading `getDeviceSoftware`. To queue the install again, use `installDeviceSoftware`.
Key: WriteScope: Company
# Clear a device custom field value
Source: https://docs.getprimo.com/api-reference/devices/clear-a-device-custom-field-value
https://api.getprimo.com/openapi.json delete /devices/{deviceId}/custom-fields/{customFieldId}
Remove the stored value for a custom field on a device. Returns the updated field (value reset to null).
Key: WriteScope: Company
# Create a device
Source: https://docs.getprimo.com/api-reference/devices/create-a-device
https://api.getprimo.com/openapi.json post /devices
Create a new device in your company.
Key: WriteScope: Company
# Delete a device
Source: https://docs.getprimo.com/api-reference/devices/delete-a-device
https://api.getprimo.com/openapi.json delete /devices/{deviceId}
Permanently delete a device from your company. The device must not be enrolled.
Key: WriteScope: Company
# Disenroll a device
Source: https://docs.getprimo.com/api-reference/devices/disenroll-a-device
https://api.getprimo.com/openapi.json post /devices/{deviceId}/disenroll
Disenroll the device from MDM. The device will no longer be managed after this operation.
Key: WriteScope: Company
# Export devices as CSV
Source: https://docs.getprimo.com/api-reference/devices/export-devices-as-csv
https://api.getprimo.com/openapi.json get /devices/export
Export the devices of your company as a paginated CSV (one row per device, first line is the header, up to 1000 devices per page). Each row contains the device attributes, its latest code of each type (recovery key, iCloud bypass code, unlock PIN, recovery OS password — see `getDeviceCodeHistory` for the full history), and one `customField.