> ## Documentation Index > Fetch the complete documentation index at: https://docs.os.default.com/llms.txt > Use this file to discover all available pages before exploring further. # Security and compliance in Default > How Default handles SOC 2, sign-in and single sign-on (SSO), roles, API keys, webhooks, MCP access, website visitor data, and SMS consent. Default has SOC 2 Type 1. Users sign in to Default through WorkOS, with single sign-on (SSO) or a one-time code sent to their email, and each member's role limits what they can see and change. This page covers the security controls in the product and links to the pages that configure them. ## SOC 2 and compliance documents | Topic | Where to find it | | - | - | | SOC 2 | Default has SOC 2 Type 1. | | Security questions | Email [security@default.com](mailto:security@default.com). | | Sub-processors | [Default sub-processors](https://www.default.com/legal/subprocessors) lists the vendors Default uses to provide its services. | | Privacy policy | [Default privacy policy](https://www.default.com/legal/privacy) | | Security overview | [Default security](https://www.default.com/legal/security) | ## Sign-in to Default Default uses WorkOS to sign users in, and WorkOS hosts the sign-in page. * **Single sign-on (SSO).** When your workspace has an active SSO connection for a verified email domain, members with that domain sign in through your identity provider. * **Email code.** Default can send a user a one-time sign-in code by email. * **Invitations.** Admins add new members to a workspace by invitation. See [Users](/settings/users). ## Single sign-on (SSO) in Default Admins set up SSO on the **Single Sign-On (SSO)** page in **Settings**, under **Workspace Settings**. Both steps run in the WorkOS **Admin Portal**, which Default opens in a single-use link that expires after about 5 minutes. 1. **Verify a domain.** Select **Add domain** and complete the DNS verification. The domain shows **Healthy** when it is verified. 2. **Set up SSO.** Select **Set up SSO** and connect your identity provider, such as Okta or Microsoft Entra. The connection shows **Active** when members can sign in through it. **Set up SSO** stays disabled until at least 1 domain is verified. Members who sign in through SSO with a domain lose access when an admin removes that domain, so Default asks the admin to type the domain to confirm. See [Single Sign-On (SSO)](/settings/enterprise). ## User provisioning in Default Default has no SCIM or directory sync. Admins add members with **Invite People** and remove them from **Users**, so joiners and leavers in your identity provider need the same change in Default. When Salesforce or HubSpot is connected, **Add from Salesforce** and **Add from HubSpot** import people to invite from your CRM. See [Users](/settings/users). ## Roles and permissions in Default Every member has 1 role: | Role | What it allows | | - | - | | **Admin** | Access to all features and actions in the workspace. | | **Member** | Specific access to selected features and actions in the workspace. | | **Viewer** | Read-only access. Viewers cannot be granted edit access. | These settings pages are for admins only: **Single Sign-On (SSO)**, **API Keys**, **Webhook Secret**, **Organization**, **Notifications**, **Notification Domains**, and **Scheduling**. Admins can connect any integration. Members can connect only their own calendar and conferencing tools. See [Integrations](/settings/integrations#access-by-role). Some workspaces also enforce granular access grants. In those workspaces, the **Users** table shows a **Permissions** column, and admins assign permission presets with **Grant access** or **Manage access**. See [Users](/settings/users). ## API keys, webhooks, and MCP access | Access | How Default secures it | | - | - | | Public API keys | Admins create keys in **Settings** → **API Keys**. Each key is shown once, at creation, and carries only the permissions selected for it: `triggers:read`, `triggers:write`, `scheduling:read`, or `scheduling:write`. Default checks the key on every request, so a revoked key stops working right away. Each key is limited to 30 requests per minute. | | Incoming webhooks | 1 **webhook secret** per workspace authenticates every incoming webhook as a bearer token. Only admins can rotate it, and rotating stops the old secret immediately. See [Webhook Secret](/settings/webhook-secret). | | MCP server (Beta) | AI clients sign in to Default through the browser, with no API key or token method. MCP tools require the **admin** or **owner** role, except the routing write tools, which follow the same queue permissions as the app: a member who can edit a queue in Default can change it through MCP. Write tools preview each change and commit only after confirmation. See [MCP server](/mcp-server#how-access-works). | The public API is server to server. It sends no CORS headers, so a browser cannot call it and the key stays on your server. See [Route and book through the API](/api/route-and-book). ## Website visitor data and the Pixel The Pixel is the script that captures form submissions on your website. It has fixed limits on what it collects: * **Sensitive fields are dropped.** The Pixel never sends the value of a field whose name contains `password`, `secret`, `token`, `key`, `auth`, `credential`, `ssn`, `credit card`, `cvv`, or `cvc`. * **Files are never sent.** File inputs are skipped entirely. * **Some paths are skipped.** Pages whose path contains `/login`, `/signin`, `/account`, `/checkout`, `/oauth`, or `/admin/` are not captured. * **You can turn capture off.** A meta tag skips a whole page, and `data-default-ignore` skips a single form or region. * **Consent is respected.** Your consent banner can withhold `analytics` or `marketing` consent with `setConsent`. Tracking is allowed until a visitor withholds consent, and form submissions are always captured. See [Privacy and data handling](/forms/privacy) for the full rules. ## Integrations and outside providers * **CRM and sequencing tools.** Admins connect them from **Integrations**. Most open the provider's own sign-in window, and a few, such as Apollo, ask for an API key. **Disconnect** removes the integration from the workspace. * **Enrichment providers.** Default supplies access to every enrichment and Website Intent provider, so you don't need an account or API key with any of them. Turning a Website Intent provider off stops Default from using it for your visitors. See [Enrichment providers](/settings/integrations/enrichment). ## SMS consent for leads When an event sends SMS messages to guests, the booking form shows SMS consent text below the phone field. Each booking-related text message is followed by a compliance message that explains why the lead received it and how to opt out by texting `STOP`. See [Events](/events#phone-collection-and-sms-consent-for-leads). ## Records of activity in Default | Record | What it shows | | - | - | | [Run logs](/workflows/run-logs) | Every workflow run: the trigger, the path it took, and what each node did. | | Routing **Assignments** | The decision record for each assignment: the queue settings, every member's score, and the member chosen. See [Queue assignments](/queues#assignments). | | Routing **Activity** | Changes to queues and their members. See [Activity log](/queues#activity-log). | Related: [Default security](https://www.default.com/legal/security) and [Default sub-processors](https://www.default.com/legal/subprocessors) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.