Track every setting against its baseline
Merges every Intune policy into one searchable index, matched by the real setting. Catches conflicts and baseline drift automatically. Free and open source.
$ irm https://intuneatlas.com/install.ps1 | iex
indexes read-only, serves on localhost · install on or · headless scan for CI · getting started guide
$ irm https://intuneatlas.com/install.ps1 | iex ✓ signed in — admin@contoso.onmicrosoft.com (read-only) ✓ 41 policies → 1,847 settings indexed in 3m 41s ✓ 11 findings · 3 critical → http://localhost:7878
What it reports
Four states. Only one of them is quiet.
Every setting in the index lands in exactly one. Anything already correct stays grey, so the output is a worklist rather than a wall of green ticks.
Two profiles disagree
Same path, different values, overlapping assignment. Both sources are printed with their value so you know which one to rescope.
Weaker than the benchmark
Checked against whichever baseline you point it at. Every finding carries a rationale and a citation, not just a severity.
Configured, reaching nothing
The profile looks healthy in the portal but targets no group. Silent, and invisible in every per-policy view.
Someone wrote down why
Notes live in a file in your repo, keyed by path. Findings print with their thread attached, so context survives the person who set it.
Baselines
A baseline is just YAML in a directory.
Ships with a small starter pack — one Microsoft rule, one CIS rule. Add your own house rules, or drop in a full benchmark like CIS or the Open Intune Baseline.
Organized by source, then baseline name and version, then OS — baselines/<source>/<baseline-name-and-version>/<os>/*.yml.
baselines/microsoft/defender-hardening-guidance/windows/tamper-protection.yml
yaml
- id: defender.tamper-protection name: Tamper protection platform: windows path: ./Device/Vendor/MSFT/Defender/Configuration/TamperProtection expect: enabled severity: critical rationale: > Any process running as SYSTEM can silently disable real-time scanning while tamper protection is off. source: Microsoft Defender for Endpoint hardening guidance
baselines/cis/windows-11-benchmark-l1/windows/quality-update-deferral.yml
yaml
- id: update.quality-deferral name: Quality update deferral platform: windows path: ./Device/Vendor/MSFT/Policy/Config/Update/DeferQualityUpdatesPeriodInDays expect: max: 7 severity: high source: CIS Microsoft Windows 11 Benchmark, L1 rationale: > Deferring quality updates (which include security patches) much beyond a week leaves known, actively-patched vulnerabilities unaddressed for longer than necessary.
Run it
Open it, query it, or wire it into CI.
One index, four entry points. The default command builds it and serves it on localhost; the rest hand you a single value, a file, or an exit code instead.
Read the index
Web UI — intuneatlas ui
Every setting grouped by category, searchable by CSP path, with sources, note threads, and the review gate for staged changes. Runs on your machine against the report on disk, with no server and no upload.
Single value
get — intuneatlas get <path>
One setting, every profile that sets it, and each value. Five lines of output, pipeable, no index served and no browser opened.
Scheduled
Headless scan
JSON or SARIF to disk and a non-zero exit when the tenant drifts past your threshold. The Docker image takes an app registration from the environment.
Continuous
GitHub Action
The headless scan on a cron, with findings as PR annotations. Fails the run at your chosen severity.
$ intuneatlas scan --baseline cis-l1 --fail-on high --format sarif 41 policies · 1,847 settings · 11 findings (3 critical, 3 high, 3 medium, 2 low) wrote ./intuneatlas.sarif exit 1 — 6 findings at or above `high`
.github/workflows/tenant-drift.yml
yaml
on: schedule: [{ cron: "0 7 * * 1" }] jobs: drift: runs-on: ubuntu-latest steps: - uses: intuneatlas/scan-action@v1 with: baseline: cis-l1 fail-on: high # exit non-zero at high or critical notes: ./intune-notes.yml
Project status
Alpha, and honest about it.
Windows coverage is solid because that's where the contributors' fleets are. Apple and Android are thinner. Here's exactly where things stand at v0.0.35.
- Windows configuration & update ringsFull CSP path resolution, conflict detection, settings catalog stable
- Compliance policies & tenant defaultsIncluding the secureByDefault check that catches unmanaged devices stable
- Enrollment, ADE tokens, certificate expiryExpiry warnings for ADE and APNs stable
- macOS & iOS payloadsIndexes and reports, but payload key mapping is incomplete, so some settings show a raw identifier partial
- Android EnterpriseWork profile restrictions only. Fully managed and dedicated devices are not mapped yet partial
-
Write-back / deploy staged changesBehind
--experimental-write. Review gate works; rollback does not yet experimental - App protection & Conditional Access policiesOut of scope for now. Different object model, would deserve its own index not planned
Contribute
Baseline rules and platform coverage, mostly.
Two contributor paths. Writing a rule needs tenant experience and no TypeScript; extending platform coverage needs the opposite. Both are wanted.