# Device deployment

> Install the SEB configuration-encryption identity onto exam devices through your device-management platform, non-extractably and scoped to SEB.

[Canonical HTML page](https://safeonlineexam.com/docs/operate/devices)

The service holds only the public certificate. For a device to open an encrypted
`.seb` configuration, it must hold the matching **private identity**, installed
through your device-management platform. This page is the device side of
[Certificate management](/docs/deploy/certificates).

This page applies when the default certificate-encryption mode is enabled. An
explicit plaintext compatibility deployment does not use a device identity; record
that lower-assurance exception and validate its remaining Config Key and session
controls separately.

<Callout type="warn" title="Never hand a student the private identity">
  Do not distribute the `.p12` or its passphrase to users, and never place either in
  an MDM script parameter. The private identity is deployed only into a protected
  MDM scope.
</Callout>

## What the profile must do [#what-the-profile-must-do]

Use your platform's certificate/profile mechanism to install the identity so that
it:

<Steps>
  <Step>
    Installs the PKCS#12 identity into the intended device or user scope.
  </Step>

  <Step>
    Marks the private key 

    **non-extractable**

     where the platform supports it.
  </Step>

  <Step>
    Restricts private-key use to the approved SEB application identity — not all applications.
  </Step>

  <Step>
    Prevents profile removal by an ordinary student account where policy supports it.
  </Step>

  <Step>
    Is scoped to a 

    **test group first**

    , then to approved assessment devices after validation.
  </Step>
</Steps>

Use the code-signing requirement and bundle/application identity documented for
your supported SEB build. A mutable filesystem path alone is **not** sufficient
application restriction.

## Managed macOS fallback [#managed-macos-fallback]

Prefer a native MDM certificate payload. When that cannot install the identity in
the required user keychain, the release bundle's
`install-seb-config-identity-user-keychain.sh` provides a controlled fallback for
managed Macs. Use it only when the MDM can stage the `.p12` and passphrase in
root-owned, mode-0600 files and run the helper as root after the intended user is
logged in. It validates the identity fingerprint and private-key match, validates
the approved SEB application, and performs the keychain import in the active
user's GUI session.

Do not turn this into a general-purpose import command: never make the `.p12`
user-readable, pass its passphrase to `security import`, or put either value in an
MDM parameter. A retryable result means the user session, login keychain, or SEB
installation is not ready yet. For Jamf School, prefer the signed in-house package
fallback from the release bundle when a native payload is unavailable. Build it
only on a secured administrator workstation, install SEB first, and test on a
small managed-device group. It is not appropriate for unmanaged or
student-administered Macs.

## Unmanaged or student-administered devices [#unmanaged-or-student-administered-devices]

An unmanaged device cannot provide the same non-extractability assurance. If a
lower-assurance activity permits such a device, use a separately scoped,
short-lived identity and document the exception — never reuse the high-integrity
assessment identity, and never hand a student the `.p12` or passphrase.

## Validate before a rollout window when encryption is enabled [#validate-before-a-rollout-window-when-encryption-is-enabled]

<Steps>
  <Step>
    Confirm the active service revision has encryption enabled and the expected certificate secret version or mounted file.
  </Step>

  <Step>
    Request 

    `${TOOL_URL}/seb/config-encryption-certificate.pem`

     and record its 

    `x-seb-public-key-hash`

    .
  </Step>

  <Step>
    Confirm the client profile reports installed on every intended test device.
  </Step>

  <Step>
    On an approved test device, run the setup check and open the encrypted setup configuration.
  </Step>

  <Step>
    Confirm Config Key proof succeeds after SEB starts.
  </Step>

  <Step>
    Confirm a device 

    **without**

     the identity cannot open the encrypted configuration.
  </Step>

  <Step>
    Confirm an unrelated app and an ordinary student account cannot export or use the private key.
  </Step>

  <Step>
    Confirm the certificate remains valid for the assessment and recovery window.
  </Step>
</Steps>

<Callout title="The setup check is not device management">
  The setup check confirms the application's SEB integration. It does not replace
  device-management policy, operating-system requirements, or a real assessment
  test. Treat it as one signal among the checks above.
</Callout>

## Platform notes from the generated policy [#platform-notes-from-the-generated-policy]

The generated configuration is strict by design. A couple of platform facts affect
your device baseline:

* **macOS** requires Automatic Assessment Configuration (AAC), installation from
  the system Applications location, and a macOS 12.1 floor. AAC may block some
  third-party assistive technology — plan such accommodations as a separately
  approved arrangement. See the [AAC glossary entry](/docs/reference/glossary#aac).
* **Windows** requires the OS-session and SEB-service controls and a supported SEB
  version floor. Client releases that do not understand a newer configuration key
  cannot enforce it, so pin the approved SEB client version and integrity baseline
  in device policy.

Always validate the complete policy with a real supported client after SEB or OS
updates. Rotation of the identity itself is covered in
[Certificate management → Rotation](/docs/deploy/certificates#rotation).