Look for exposed DKIM CNAMEs, predictable MX answers, tenant ID resolution through public OpenID endpoints, and repeated authenticated or unauthenticated lookup activity across Microsoft identity surfaces. If these signals can be correlated into tenant naming and related-domain discovery, the environment is still leaking useful reconnaissance data even without the old ACS endpoint.
How to tell whether identity discovery is still leaking
The practical test is whether public artefacts still let an outsider map tenants, domains, and identity infrastructure without privileged access. If DKIM, MX, and OpenID signals can be combined into tenant naming or related-domain discovery, then discovery leakage is still happening, even if the old obvious endpoint is gone. The question is less about one endpoint and more about whether the identity footprint is still correlatable.
That matters because discovery leakage is often passive at first: a resolver, mail lookup, or identity metadata request can expose enough structure for an attacker to build a target list. Teams should assume the leak is real when multiple low-signal clues line up consistently across the same tenant or brand.
What the main leakage signals actually tell you
Exposed DKIM CNAMEs can reveal mail service relationships, predictable MX answers can reveal naming patterns, and public OpenID endpoints can disclose tenant identifiers or issuer details. None of those signals alone proves a serious exposure, but together they can make tenant naming and related-domain discovery routine rather than exceptional. That is the material issue: the environment is helping an outsider infer identity boundaries.
Repeated authenticated or unauthenticated lookup activity is another useful indicator because it shows the surface is still being probed for structure. If those lookups return stable, reusable naming patterns, the leak is not just theoretical. In practice, the attacker does not need the old endpoint when public identity surfaces still behave like a directory.
Useful verification is straightforward: compare what a fresh outsider can infer today with what should have been obscured, and check whether the same tenant can be reconstructed from more than one public source. If the answer is yes, the leakage condition remains active.
Why this matters even after the old endpoint is gone
Removing one exposed endpoint rarely removes the underlying discovery path. Identity ecosystems often leave behind enough mail, federation, and metadata breadcrumbs that a determined analyst can still link a tenant to its domains, brands, or environment segments. That is why teams should treat discovery control as a broader exposure problem, not as a single-URL cleanup exercise.
For readers who want a broader lifecycle view of this problem, the NHI Lifecycle Management Guide is useful because discovery, inventory, ownership, and offboarding all sit on the same control plane. When visibility is incomplete, exposure tends to persist through stale records, unused names, and forgotten trust relationships.
Teams should also recognise that discovery leakage often creates a stepping stone for follow-on abuse. Once an outsider can reliably infer tenant naming, they can improve phishing pretexting, target federation abuse, or focus credential attacks on the most plausible related domains. That makes discovery leakage an enabler, not just a reconnaissance curiosity.
Risk and Threat Considerations
Discovery leakage increases exposure because it lowers the cost of targeting the right tenant, brand, or partner relationship. The attacker does not need full compromise to benefit, only enough public structure to reduce ambiguity and improve the next stage of recon.
Failure mechanism: Public DNS, mail, and OpenID metadata disclose stable naming patterns or tenant identifiers, which can then be correlated across multiple identity surfaces into a usable map of the environment.
Impact: Attackers gain better pretexting, more accurate targeting, and a cleaner path to phishing, federation abuse, or credential attacks against the right tenant and related domains.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Identity leakage often feeds attacks against organizational authentication surfaces. |
| IA-9 — Identification and Authentication (Service and Non-Organizational Users) | Public tenant discovery often exposes service and federation surfaces used by non-human actors. | |
| AU-2 — Event Logging | Repeated lookup activity is a detection signal that depends on audit visibility. | |
| Recommendation — Harden organizational authentication paths that could be targeted after tenant discovery. Apply strong service authentication controls to exposed identity and federation endpoints. Log identity-surface lookups so repeated discovery probing is observable and reviewable. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Discovery leakage often persists when identity endpoints and metadata are not fully inventoried. |
| Recommendation — Inventory and review exposed identity-related endpoints to close residual discovery paths. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and systems are monitored to detect potential cybersecurity events | Repeated lookup patterns should be monitored as potential reconnaissance activity. |
| Recommendation — Monitor identity-related lookup activity for reconnaissance patterns across public surfaces. | ||
Practitioner Guidance
What to verify: Test whether an unauthenticated observer can still correlate at least two different public signals into a tenant or domain map. If DKIM, MX, and OpenID responses all point to the same identity structure, assume the leak is still operational.
What practitioners underestimate: Teams often remove the most obvious endpoint and then stop, but the remaining discovery surface can be more valuable because it is distributed across ordinary infrastructure. The harder case is not a single exposure, it is repeated low-grade disclosure that stays consistent over time.
Practitioner takeaway: Treat discovery leakage as fixed only when outside observers can no longer reliably link mail, federation, and naming artefacts into the same tenant story.
Related resources from NHI Mgmt Group
- How can security teams tell whether an identity path is still safe to keep?
- How can security teams tell whether automation is helping or harming identity governance?
- How can security teams tell whether their identity programme is ready for zero trust?
- How can IAM teams tell whether identity security coverage is real or just broader branding?