Device deployment

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

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.

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.

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.

What the profile must do

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

Installs the PKCS#12 identity into the intended device or user scope.

Marks the private key non-extractable where the platform supports it.

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

Prevents profile removal by an ordinary student account where policy supports it.

Is scoped to a test group first, then to approved assessment devices after validation.

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

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

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

Confirm the active service revision has encryption enabled and the expected certificate secret version or mounted file.

Request ${TOOL_URL}/seb/config-encryption-certificate.pem and record its x-seb-public-key-hash.

Confirm the client profile reports installed on every intended test device.

On an approved test device, run the setup check and open the encrypted setup configuration.

Confirm Config Key proof succeeds after SEB starts.

Confirm a device without the identity cannot open the encrypted configuration.

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

Confirm the certificate remains valid for the assessment and recovery window.

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.

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.
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.