Downloading the STIG takes a minute. Turning 50-odd requirements into an enforced fleet configuration — through the right mix of native Android Enterprise policy and Knox Service Plugin — is where programs lose weeks. This is the map.
This is the misconception that costs the most time. STIG fix text is written UEM-agnostically — it names a generic Android Enterprise restriction and the underlying API, not a Knox Service Plugin toggle. A typical fix reads like "in the device restrictions, set 'Debugging Features' to 'Disallow'. API: addUserRestriction, DISALLOW_DEBUGGING_FEATURES."
So the mapping is a two-step decision, made per requirement: most rules are satisfied by native Android Enterprise policy in your UEM; a subset requires Knox/KPE APIs, and the rule text signals those by mentioning "KPE policy" or "Knox KPE APIs". Knox Service Plugin is the delivery mechanism for that subset — not for the whole baseline.
Before OEMConfig, every UEM vendor had to integrate a separate SDK for every device manufacturer whose special features you wanted to manage. OEMConfig replaces that with a single channel: the manufacturer publishes an app to managed Google Play, that app declares a managed configuration schema, and your UEM renders that schema as a configuration form. The UEM passes your settings to the app, and the app calls the manufacturer's privileged APIs on-device.
The consequence worth internalizing: your UEM is not interpreting these settings. It is transporting them. Microsoft's documentation for Intune says this plainly — Intune "doesn't validate or change the schema provided by the app," so an incorrect configuration still gets sent to devices.
KSP is Samsung's OEMConfig app — package name com.samsung.android.knox.kpu. It is
not preloaded; you deploy it from managed Google Play through your UEM. It
supports Device Owner, Profile Owner and COMP modes, and runs on Samsung devices with Android 9
or later and Knox 3.2.1 or later.
Its value is decoupling. New Knox policies ship as KSP app updates rather than waiting for each UEM vendor to build support. DISA's own supplemental guidance describes the mechanism and states that KSP is approved for DoD use.
On a COPE or work-profile device the same capability frequently appears twice, once under Device-wide and once under Work profile. Setting only one of them is a common and silent failure.
One OEMConfig profile per device. Assigning multiple OEMConfig profiles to the same device produces inconsistent behavior. Configure each top-level group in exactly one profile — which means a STIG baseline split across several admin-authored profiles will misbehave.
Master toggles. Nearly every policy group has an enabling switch —
Enable device restriction controls, Enable certificate management
controls, Enable firmware controls. Children are inert without it. This is the
single most common reason a KSP policy silently does nothing.
Per-setting Knox minimums. A setting appearing in your console does not mean the device honors it. Individual settings carry their own Knox version requirements — the real compatibility surface is per-setting, not per-KSP-release.
License expiry. The free KPE Premium key expires two years from activation, and activation requires reaching Samsung's licensing server. A lapsed key can silently drop premium-gated controls out of your baseline.
STIG Viewer 3.x consolidates what used to be three separate tools — the old viewer, the applicability guide and checklist functionality. It opens XCCDF-formatted STIGs in readable form, builds a library across multiple STIGs, and produces the checklist you will be assessed against.
It accepts XCCDF XML, ZIP archives including nested ZIPs, CSV, SCAP results, and existing
.ckl / .cklb checklists. It exports HTML, CSV, text, CMRS XML,
.ckl, and .cklb — the last of which is the eMASS-compatible format you
almost certainly want.
"The Samsung Android STIG" is ambiguous, and getting this wrong wastes a review cycle. A downloaded package normally contains separate COBO and COPE benchmarks, and there is a distinct BYOAD STIG for personally owned devices. Pick the benchmark matching your use case before you build the checklist.
For scale: the Samsung Android 16 COPE benchmark ran to roughly 48 requirements — about 2 CAT I, 37 CAT II and 9 CAT III. Expect a similar shape per benchmark, weighted heavily toward CAT II. Open your specific benchmark in STIG Viewer for the exact count.
Every Samsung STIG ZIP includes a supplemental document developed jointly by Samsung and DISA — and almost nobody opens it first. It defines the approved use cases, the approved device list, and which Samsung services are DoD-approved (Knox Service Plugin, Knox E-FOTA and Knox Mobile Enrollment all are). It also carries newer content such as the AI restrictions: cloud-based AI processing prohibited, on-device inference permitted.
It also draws a boundary worth knowing: DualDAR configuration is explicitly out of scope of the STIG. DualDAR is a CSfC capability the STIG acknowledges but does not require. Do not present it as a STIG step.
Follow this sequence and the expensive discoveries happen in week one instead of at assessment.
Samsung STIG packages are named per OS release with a date token — the version string changes each quarterly republication. Get the one matching the OS you will actually field, not the newest one on the page.
Approved use cases, approved devices, and which Samsung services are DoD-approved. Fifteen minutes here saves days later. Confirm your device models appear in its list.
COBO, COPE with Work Profile, or COPE with Separated Apps. Load that benchmark into STIG Viewer and create your checklist. Loading the wrong one produces a clean checklist against the wrong requirements.
Native Android Enterprise policy · Knox/KPE policy via KSP · procedural or user-based enforcement · not applicable to this use case. This triage is the actual intellectual work of the engagement, and it is what a mapping document cannot do for you.
Most requirements land here — device restrictions, password policy, lock timeout, app controls. Standard Android Enterprise policy, no Knox involved.
Enter the KPE Premium license key. Enable device policy controls and, where applicable, work profile policy controls. Then enable each policy group's master toggle before configuring its children. Remember: one OEMConfig profile per device.
The STIG is versioned to an OS release. An uncontrolled consumer update can move a device off the version your baseline was written against — or leave it behind on an unpatched build. E-FOTA is what makes "the fleet is on the covered OS version" enforceable rather than aspirational.
The check text is written as on-device verification steps — tap Build Number and confirm developer options are blocked, and so on. Do this on a real device, not from the console's compliance view.
Document every exception with its justification. Findings you cannot meet are normal; findings you cannot explain are not.
KSP exposes roughly thirty policy groups. These are the ones that carry STIG-relevant controls. Setting names below are as Samsung's documentation renders them — including its inconsistent capitalization.
Hardware and debugging controls — where several CAT I and CAT II rules land.
Master: Enable device restriction controls
Allow microphone · Allow Camera · Allow Video Recording ·
Allow developer mode · Allow USB debugging ·
Allow USB media player · Setup USB exception list
Screen capture is not in this group — use the native Android Enterprise restriction.
Where revocation-checking requirements are satisfied — these genuinely need Knox APIs.
Master: Enable certificate management controls
Enable revocation check · Enable OCSP check before CRL ·
List of Apps to enable for validation · Add trusted CA certificate ·
Block User from removing certificate
Watch out: the "Enabled for all apps" option is deprecated on Knox 3.12 and later.
A legacy baseline carrying it will misbehave on current firmware.
The E-FOTA hook — how you keep the fleet on the OS version your STIG covers.
Master: Enable firmware controls
Allow firmware update over-the-air ·
Allow firmware update in recovery mode ·
Enforce firmware auto update on Wi-Fi ·
Enable E-FOTA client installation & launch
Present identically under both Device-wide and Work profile trees — set both where applicable.
Master: Enable Audit Log
Audit Log Policies · Audit Log Outcome ·
Audit Log Severity Level · Audit Log Frequency
Samsung's documented support range for this group looks stale relative to current Android
releases — verify behavior on your firmware before relying on it for a control.
Sources: Samsung Knox Service Plugin documentation; Knox E-FOTA documentation; Android Enterprise OEMConfig; DISA STIG Viewer 3.x User Guide; DISA Samsung Android supplemental procedures; NIST National Checklist Program. Current as of August 2026.
Background on Knox and the Tactical Edition line, plus direct links to every Samsung certification registry.
The triage step is where most engagements stall — deciding which requirements are AE-native, which need Knox, and which are procedural. That is exactly the conversation to have.