Microsoft: Eight CISO Best Practices Tighten Token Reach Before Detections

Rico Mariani, Deputy CISO for Microsoft Security Products, Research Infrastructure, and Engineering Systems, has spent his first six months publishing a set of CISO best practices for the risk-review checklist his team applies to engineering systems. The result, published on the Microsoft Security Blog and drawn from his work with the broader Microsoft Deputy CISO group, is an eight-point list that drops several familiar entries and orders the remaining ones from “what an attacker wants” toward “what a foothold actually gets them.”

• Microsoft stopped $4 billion in fraud attempts between April 2024 and April 2025, and is tracking 100 trillion security signals per day – 40% more than in 2023.
• The eight CISO best practices begin with assets and applications and end with auditing and “things not to miss”; the load-bearing four in the middle are authentication, authorization, network isolation, and detections.
• Fungible tokens – those granting a generic capability across customers, users, or data – are flagged as the most consequential authentication failure mode, even when the token issuer is sound.
• Backup data, support systems, and development/test environments are explicitly named as the assets a CISO risk review most often skips.

Why these eight CISO best practices, and why this order

Mariani frames the rebuild as a synthesis of his performance- and systems-engineering background with the security-specific perspective he has absorbed from the other Microsoft Deputy CISOs. The departure from a stock asset-inventory checklist is the ordering: assets first, then applications, then a four-step run through authentication, authorization, network isolation, and detections, then auditing and a category Microsoft labels “things not to miss.” Each step inherits constraints from the one before it. Identifying the assets a cyberattacker would actually want defines the scope; identifying the applications that touch those assets defines the surface; the four middle steps define the controls that limit what one foothold can reach; auditing and the overlooked-systems sweep close the post-breach gap.

The framework treats the eight CISO best practices as a single risk-review conversation, not eight independent checklists. Mariani’s caution at the start – “what I’m about to tell you is only approximately correct” – lands as a working assumption rather than a hedge: the eight items are conversation starters, designed to surface the specific exceptions and architectural choices that make a given engineering system different. The risk review’s value is in the discussion the questions produce, not in the binary pass/fail score.

The fungible-token problem is what most CISO risk reviews still miss

Mariani’s contrarian observation lives in the authentication and authorization sections. A standard CISO risk review will inspect whether tokens are issued by a hardened system (Microsoft Entra in the worked example, or any other standards-track issuer) and stop there. The Microsoft framework keeps going. Even with a good issuer, the operational risk is tokens that are too fungible, too long-lived, or too generic. A token that authorises a capability “for anyone, anywhere” is a token that, if found in a stray cache or log, gives a cyberattacker leverage across the entire customer base. A token scoped to a single customer, on behalf of a single user, for a defined set of data is the same authentication primitive constrained to roughly one blast-radius worth of damage.

The authorization half of the same problem is enforcement. Mariani flags ad hoc authorization code – hand-rolled checks scattered across handler functions – as the recurring failure mode where good tokens deliver no protection. The framework’s recommendation is declarative authorization patterns that verify token claims against the incoming API and the data being accessed, with the same library code running across every endpoint. Simple, consistent authorization yields fewer bugs and therefore less risk; the principal claim is structural rather than philosophical. This is the reason network isolation lands next in the eight: it is the second perimeter that contains a token a cyberattacker has stolen but cannot yet use.

The pair of authentication and authorization sections is where the published framework departs most sharply from the security-vendor checklist genre. The vendor checklist’s typical authorization question is “do you use single sign-on with multifactor”; Microsoft’s question is “what is the smallest capability the most powerful token in your system can grant, and how is that token enforced.” The contrarian observation that the token system is sound but the tokens themselves are too powerful is what an asset-first risk review tends to miss until the assume-breach exercise lands one in the wrong logfile.

Apply the framework to the systems your risk review usually skips

Mariani’s eighth item – “things not to miss” – names the assets a CISO risk review most often skips, and the sequence below applies the preceding seven steps specifically to those.

Run the asset and application steps on backup data first. A cyberattacker who cannot reach the primary store often finds the backups entirely unprotected; the eight CISO best practices apply equally to them. Inventory backups as assets, identify the applications that read or restore them, and test whether the authentication and authorization controls applied to the primary store are also applied to backups. The Microsoft framework names this as the clearest single gap.

Apply the fungible-token check to support and customer-service systems. Customer support workflows frequently require access to customer data and tend to inherit the most permissive token scopes in the codebase. Confirm the support tokens are scoped to a single customer per session and that the support application enforces authorization on every API rather than at first login. Where this fails, the eight CISO best practices are doing their work: identifying the assets, applications, authentication, and authorization gaps in the order the framework prescribes.

Treat development and test environments as exception-prone production. Development code carries more bugs than production code by definition, and a meaningful fraction of those bugs are authorization bugs. Apply the same risk-review steps with the assumption that the controls are weaker; isolate development environments at MITRE ATT&CK-relevant network levels and ensure auditing covers test-system access to anything that touches a production asset. The framework’s “approximately correct” caveat is most relevant here, where exceptions multiply.

Make detection and auditing distinct in your CISO risk-review language. Mariani separates the two deliberately: detection alerts on threat-model evidence in real time; auditing reconstructs what a cyberattacker accessed after a breach. A risk review that conflates them produces incident response that is fast but blind to scope, or thorough but slow. Score the two functions separately on every system the asset inventory surfaces. Mariani’s first six months as Deputy CISO have produced the eight CISO best practices as a reusable artefact; the next six will test whether engineering teams adopt the ordering or reach for the asset-first checklist they already had.