A tenant is over-trusting CBA when a small number of role holders can change binding modes, add trusted certificate authorities, or make certificate sign-in satisfy MFA requirements. Those are trust-anchor changes, so they should be monitored as privileged identity events, not routine configuration updates.
Why This Matters for Security Teams
Certificate-based authentication becomes dangerous when it is treated as inherently trustworthy instead of as one factor in a larger identity decision. A certificate can prove possession of a private key, but it does not automatically prove the caller should satisfy MFA, inherit broad access, or be allowed to change trust anchors. That gap matters most in tenants where a few administrators can alter binding modes or add certificate authorities without privileged review.
NIST’s NIST Cybersecurity Framework 2.0 emphasizes continuous governance over identity and access, not one-time trust assumptions. In NHI programs, the same principle applies to certificates: the control plane around trust is as important as the cryptography inside the certificate. NHIMG research shows that machine identity management is still widely manual, with 57% of organisations lacking a complete inventory of their machine identities, which makes over-trust harder to spot and easier to inherit silently. In practice, many security teams discover over-trust only after a certificate path has already been used to bypass conditional access or expand MFA-equivalent access.
How It Works in Practice
Security teams should start by mapping where certificate authentication is allowed to influence sign-in outcomes. The key question is not whether certificates exist, but whether they can satisfy policy outcomes that were meant to be reserved for stronger assurance. If a certificate can unlock access, then the issuance chain, trust anchors, binding mode, and administrative permissions around those settings become privileged identity controls.
In a mature review, teams look for three signs of over-trust:
- Certificate sign-in is treated as MFA by default, even when the certificate was issued outside the tenant’s highest-assurance path.
- Small numbers of role holders can add or replace trusted certificate authorities without privileged workflow approval.
- Binding mode changes are made through routine configuration channels instead of monitored identity administration events.
That operational view aligns with NIST guidance on identity assurance and with current NHI guidance from NHIMG, including the Ultimate Guide to NHIs — What are Non-Human Identities, which is useful for distinguishing the certificate itself from the identity it represents. Teams should also watch for the same pattern seen in the Sisense breach and similar incidents: once trust is embedded in a central identity control, abuse looks like legitimate administration until access is traced end to end. Current guidance suggests logging and alerting on trust-anchor changes, not just on failed authentications or certificate expiry. These controls tend to break down in hybrid tenants with legacy federation, because certificate paths, conditional access, and external CA trust often overlap without a single authoritative owner.
Common Variations and Edge Cases
Tighter certificate controls often increase administrative overhead, requiring organisations to balance assurance against operational latency. That tradeoff is especially visible when older applications depend on certificate mapping that was built before modern identity governance existed.
There is no universal standard for this yet, but best practice is evolving toward treating certificate trust as a privileged control plane. The main edge cases are legacy devices, shared service accounts, and federated environments where a certificate may be one of several authentication paths. In those environments, a certificate can be acceptable for authentication but still inappropriate as proof of MFA-level assurance.
Security teams should be cautious when:
- a certificate authority is external to the tenant but still accepted as fully trusted,
- certificate-based sign-in is allowed to bypass step-up authentication, or
- administrators can modify certificate trust without change review or alerting.
NHIMG’s machine identity research shows why this matters operationally: certificate lifecycle management is still only partially automated in many organisations, which increases the chance that trust changes go unnoticed. The right response is to classify trust-anchor changes as privileged identity events, then monitor them with the same rigor as role elevation or MFA policy changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers insecure trust and credential lifecycle controls for non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Identity and access governance applies directly to certificate trust decisions. |
| NIST AI RMF | Risk governance helps classify trust-anchor changes as high-impact identity decisions. |
Assign owners for certificate assurance decisions and review them as part of AI or automation risk governance.
Related resources from NHI Mgmt Group
- How can security teams know whether workspace agent tokens are being over-trusted?
- How do security teams know whether OIDC-based roles are actually safe?
- How do security teams know whether intent-based classification is working for AI content?
- How do security teams know whether an ingestion service is over-privileged?
