OID-See v1.0.1 is out 🎉
This is a precision release.
No shiny new dashboards.
No dramatic architectural upheaval.
Just tighter logic, fewer false positives, and a scoring model that better reflects how Entra actually behaves in the real world.
If you’re already using OID-See, this release should feel immediately calmer - and more trustworthy.
👉 Release: https://github.com/OID-See/OID-See/releases/tag/v1.0.1
Why this release exists
As more people started using OID-See against real tenants (including very large and very messy ones), a few things became clear:
- Some signals were technically “true” but operationally misleading
- Some risk factors needed context gating, not raw scoring
- A couple of heuristics were doing too much too early
v1.0.1 is about fixing that.
This release is the result of:
- Dogfooding against production Entra tenants
- Feedback from identity architects and defenders
- Me getting annoyed at my own tool for shouting when it shouldn’t 😄
What’s changed in v1.0.1
🔧 App role assignment risk — fixed
Previously, apps with appRoleAssignmentRequired = false could still pick up elevated risk purely due to assignment counts.
That’s backwards.
In v1.0.1:
- Assignment count alone no longer materially increases risk
- Exposure is correctly driven by “assignment not required”
- Privileged roles and scopes are now the deciding factor
This dramatically reduces noise for:
- Microsoft first‑party apps
- Broadly accessible SaaS integrations
- Legitimate enterprise tooling
👤 Ownership: governance vs security
Apps with no owners were previously treated as a security risk. Per Glenn Van Rymenant’s analysis, this increases risk rather than indicating security hygiene. Apps with no owners have reduced mutation attack surface; apps with user owners have highest risk.
In reality:
- This is often a governance gap
- Especially common with third‑party and gallery apps
Now:
- “No owners” is flagged as a governance issue
- It no longer inflates core security risk scoring
- Still visible, still actionable - just correctly classified
🎭 Deception logic — gated and smarter
The deception heuristic has been tightened significantly.
Previously, publisher/app name mismatches could trigger deception signals even when:
- The app was unverified
- The publisher surface wasn’t trustworthy to begin with
In v1.0.1:
- Deception checks are gated behind
verifiedPublisherId - Additional logic handles identity‑laundering patterns, such as:
- Microsoft‑looking publisher names
- MSA‑style tenants
- Non‑Microsoft reply URLs and domains
Result: fewer false alarms, stronger signals when it really matters.
What didn’t change (on purpose)
- The data model
- The JSON schema
- The graph visualisation approach
- The “explainable risk” philosophy
This release is intentionally conservative.
No breaking changes. No schema churn.
What’s next
v1.0.1 clears the ground for bigger things:
- Better signal composition
- More defensible scoring explanations
- Cleaner separation between security risk, governance risk, and design trade‑offs
- Deeper first‑party vs third‑party differentiation
If you’re using OID-See to support:
- Identity risk assessments
- App governance conversations
- Conditional Access strategy
- “Why is this risky?” discussions with stakeholders
This release should make those conversations easier.
Feedback welcome (seriously)
OID-See is shaped by real‑world usage.
If you spot:
- Scoring that feels off
- Signals that lack context
- Things that make you mutter “yeah but…”
Open an issue, start a discussion, or shout at me on LinkedIn / Slack / Mastodon.
Because tools should get better the more they’re used - not louder.