Microsoft Configuration Manager (SCCM)

This guide is for IT admins deploying Dev Machine Guard to a fleet of Windows endpoints through Microsoft Configuration Manager (formerly SCCM, now part of the Microsoft Intune family as MEMCM / ConfigMgr).

SCCM consumes the Dev Machine Guard MSI natively as a Windows Installer (*.msi) Application deployment type. Detection rule and uninstall command are auto-derived from the MSI ProductCode, so no scripting is required on your side.

What ships

• stepsecurity-dev-machine-guard-<version>-x64.msi (Windows on Intel/AMD)
• stepsecurity-dev-machine-guard-<version>-arm64.msi (Windows on ARM)

Download the MSI for your architecture from GitHub Releases.

Two ways to pass tenant credentials

	Option A: Inline properties	Option B: Pre-staged bootstrap file
Set up	One step (MSI deploy)	Two steps (drop config, then MSI deploy)
API key in logs	Appears in AppEnforce.log if /l*v is on	Never on command line, safe under any logging
Multi-tenant	One Application per tenant (different command line)	One Application; per-tenant config via GPO/Intune File preferences
Recommended	OK for small or lab deployments	Yes for production

Option A: Inline properties

Use this in the SCCM Application's Installation program field:

msiexec /i "stepsecurity-dev-machine-guard-<version>-x64.msi" /qn ^
  CUSTOMERID="acme-corp" ^
  APIENDPOINT="https://agent.api.stepsecurity.io" ^
  APIKEY="step_xxxxxx" ^
  SCANFREQUENCY=4 ^
  /l*v "C:\Windows\Temp\dmg-install.log"

Property	Required	Description
CUSTOMERID	Yes	Your StepSecurity tenant ID
APIENDPOINT	Yes	StepSecurity backend URL (typically https://agent.api.stepsecurity.io)
APIKEY	Yes	Tenant API key from your StepSecurity dashboard
SCANFREQUENCY	No	Scheduled scan frequency in hours (default 4)

Option B: Pre-staged bootstrap file (recommended)

Step 1. Deploy a JSON config to every target endpoint via GPO File Preferences, Intune Settings Catalog → Files, or any other config distribution channel. Path:

C:\ProgramData\StepSecurity\bootstrap.json

Contents:

{
  "customer_id": "acme-corp",
  "api_endpoint": "https://agent.api.stepsecurity.io",
  "api_key": "sk_live_xxxxxxxxxxxxxxxx",
  "scan_frequency_hours": "4"
}

Step 2. Deploy the MSI with the BOOTSTRAPFILE property pointing at that path:

msiexec /i "stepsecurity-dev-machine-guard-<version>-x64.msi" /qn ^
  BOOTSTRAPFILE="C:\ProgramData\StepSecurity\bootstrap.json" ^
  /l*v "C:\Windows\Temp\dmg-install.log"

The API key never appears on the msiexec command line, so it stays out of AppEnforce.log even with verbose logging enabled. The bootstrap file can be ACL-restricted to SYSTEM and Administrators if you want defense-in-depth.

A note on the persisted config.json and multi-user machines

Either deployment path writes the resolved config, including api_key in plaintext, to C:\ProgramData\StepSecurity\config.json on each endpoint. This is required because the scheduled task runs under the logged-in user's context and needs to read the config at scan time.

The installer hardens the file's ACL on write to:

• NT AUTHORITY\SYSTEM — Full Control
• BUILTIN\Administrators — Full Control
• BUILTIN\Users — Read

Inheritance is disabled. So any logged-in user can read the API key (necessary for the scanner), but cannot modify it. On a single-user developer workstation this is the expected security posture.

On a shared multi-user machine (kiosk, lab workstation, RDS host) every interactive user can read the tenant API key from config.json. If that is not acceptable for your environment:

• Use the BOOTSTRAPFILE path and tighten the bootstrap file's ACL yourself (the installer only manages config.json's ACL).
• Or scope deployment to single-user machines via SCCM collection requirements.

DPAPI-backed storage is on the roadmap. Open a feature request to register interest.

SCCM Application setup, step by step

Step 1: Go to Software Library → Applications → Create Application.

Step 2: Select Manually specify the application information and fill in:

• Name: StepSecurity Dev Machine Guard
• Publisher: StepSecurity
• Software version: matches the MSI you are deploying (e.g., 1.11.3)

Step 3: Add a Deployment Type and select Windows Installer (*.msi).

Step 4: Under Content, point at the .msi file on a share that the Distribution Points can pull from.

Step 5: On the Programs tab:

• Installation program: use the command from Option A or Option B above.
• Uninstall program: SCCM auto-fills from the MSI ProductCode, usually msiexec /x {PRODUCT-CODE} /qn. Accept the default.

Step 6: For Detection method, accept SCCM's offer to use the MSI's product code. No custom script needed.

Step 7: On the User Experience tab:

• Installation behavior: Install for system
• Logon requirement: Whether or not a user is logged on
• Installation program visibility: Hidden

Step 8: On the Requirements tab:

• For the x64 MSI: Operating system → Windows → All Windows 10/11 (64-bit) and Windows Server 2016+ (64-bit)
• For the arm64 MSI: same selection but the ARM64 variant

Step 9: Deploy to a test collection first (5 to 10 machines), then expand to the full fleet.

Validating a successful deployment

After SCCM reports the install as complete, on a target endpoint:

:: 1. The binary is on disk
dir "C:\Program Files\StepSecurity\stepsecurity-dev-machine-guard.exe"

:: 2. The scheduled task is registered
schtasks /query /tn "StepSecurity Dev Machine Guard"

:: 3. The config landed where the scanner can read it
type "C:\ProgramData\StepSecurity\config.json"

:: 4. (Optional) trigger an immediate scan to confirm end-to-end
"C:\Program Files\StepSecurity\stepsecurity-dev-machine-guard.exe" send-telemetry

The configured tenant should see the endpoint in the StepSecurity dashboard within a few minutes.

Upgrades

When a new version ships, create a new Application in SCCM with the new MSI and mark it as superseding the previous Application:

Step 1: On the new Application, open the Supersedence tab and click Add, then pick the old Application.

Step 2: Choose Uninstall for the old app. The new MSI's MajorUpgrade will do the uninstall atomically, but SCCM needs the supersedence link to track which endpoints to push the upgrade to.

Step 3: Deploy the new Application to the same collection.

On each endpoint:

• SCCM pushes the new MSI on its next policy cycle (default 60 minutes).
• Windows Installer recognizes the upgrade (same UpgradeCode, higher Version) and atomically uninstalls the old version (removing the scheduled task via the uninstall custom action), then installs the new one (re-registering the task with the new binary).
• The per-tenant config at C:\ProgramData\StepSecurity\config.json is preserved across upgrades, so tenant configuration is retained automatically.

Uninstall

The SCCM uninstall fires the msiexec /x {ProductCode} command. Dev Machine Guard's custom action runs before file removal and calls stepsecurity-dev-machine-guard.exe uninstall, which removes the scheduled task via schtasks /delete. MSI then removes the executable and empties C:\Program Files\StepSecurity\.

The config at C:\ProgramData\StepSecurity\config.json is not removed by MSI, since it lives outside the install scope. If you want a clean uninstall, add this as a post-uninstall cleanup step in SCCM or via GPO:

rmdir /s /q "C:\ProgramData\StepSecurity"

Troubleshooting

Symptom	Likely cause	Where to look
MSI exit code 1603	Custom action failed (bad credentials, schtasks denied)	C:\Windows\Temp\dmg-install.log (msiexec verbose log)
Scheduled task missing	install custom action skipped or failed	Same log; search for RunInstallScheduledTask
Endpoint not reporting to dashboard	Wrong API key or endpoint	type C:\ProgramData\StepSecurity\config.json
Endpoint config still under %USERPROFILE%\.stepsecurity\	MSI ran without elevation (should not happen via SCCM)	Verify SCCM Application is set to "Install for system"

When opening a support case, attach:

C:\Windows\Temp\dmg-install.log    (msiexec verbose log)
C:\ProgramData\StepSecurity\agent.log         (scanner output)
C:\ProgramData\StepSecurity\agent.error.log

Verifying the MSI before deployment

Before pushing an MSI to SCCM, run this check on a test workstation to confirm the file came from StepSecurity and has not been tampered with. This is a second integrity check, independent of the Windows publisher signature (Authenticode) that Windows already verifies at install time.

Files to download

From the GitHub release page, grab both files below for each architecture (x64 or arm64) you deploy:

• stepsecurity-dev-machine-guard-<version>-<arch>.msi
• stepsecurity-dev-machine-guard-<version>-<arch>.msi.sha256.sig

Download and run the verifier

Invoke-WebRequest `
  -Uri "https://raw.githubusercontent.com/step-security/dev-machine-guard/main/scripts/verify-msi.ps1" `
  -OutFile ".\verify-msi.ps1"

.\verify-msi.ps1 .\stepsecurity-dev-machine-guard-<version>-<arch>.msi

Success exits 0 and prints:

[OK]    Signature VERIFIED - MSI is authentic and untampered.

If verification fails

Do not deploy the MSI. Re-download both files from the official GitHub release and retry. If a fresh download still fails, contact [e-mail].