Cybersecurity briefing
/
feb 16, 2025
Stolen Credentials Are Only the Start. Control Where They Can Go.
Microsoft's Defender Experts data links valid accounts to 20% of observed initial access. Here's how to limit where a stolen credential can go.
/
AUTHOR
Jeff Dyer
Overview
Microsoft’s Digital Defense Report, released October 1, describes attacks becoming faster as threat actors incorporate AI into their operations. Its findings also point to a familiar weakness: access obtained through trusted identities. For organizations with a mix of cloud applications, Active Directory, and older business systems, the practical question is whether a stolen credential can keep opening doors while the security team investigates.
A valid account can still be an attacker’s account
In Microsoft’s analysis accompanying the report, valid accounts accounted for 20% of observed initial access in Microsoft Defender Experts data. That is a finding from Microsoft’s observations, not a census of every intrusion. Microsoft also cautions that most complex real-world attacks still involve meaningful human direction. The lesson is not that every attacker is autonomous; it is that automation can accelerate familiar techniques without requiring a new weakness.
Authentication answers whether someone or something can present acceptable proof of identity. It does not establish that the person using that proof is acting legitimately, or that every resource reachable by the account is appropriate. A password can be correct while its use is malicious. Permissions that made sense for yesterday’s administrator or integration can become an attacker’s route to another system.
Consider a hypothetical compromised workstation. An attacker obtains an account that can authenticate to several internal servers. A successful first login may produce an alert, but the next server request can occur before an analyst finishes reviewing it. The useful containment question is therefore specific: can policy deny that next request, based on the identity, source, destination, and available risk context?
The first sign-in is not the last access decision
Strong, phishing-resistant MFA remains an important defense at entry points. Organizations should also map what happens after that entry: administrative connections, file access, scheduled jobs, and service-to-service authentication. A protected cloud sign-in should not be treated as evidence that every internal access path has equivalent controls. Each path needs its own coverage assessment.
NIST’s zero trust architecture guidance separates authentication from authorization and rejects implicit trust based on network location. In operational terms, getting onto the network should not confer unrestricted access across it. Teams need to identify where access is evaluated, what information informs the decision, and which component can enforce a denial before the requested session is established.
This is a different responsibility from investigating an alert. Investigation establishes what happened and which systems may be affected. Runtime enforcement acts on a covered access request while it is being processed. Both matter: an accurate investigation can guide containment, while a pre-established access rule can restrict movement without waiting for that investigation to finish.
For supported identity paths, Silverfort’s Runtime Access Protection architecture illustrates how that control can work alongside existing IAM infrastructure. The IAM system forwards an access request for risk analysis and inline policy enforcement, then uses the returned verdict to grant or deny access. Its Authentication Firewall supports identity-based deny and segmentation policies, including across Active Directory resources. The relevant protocol, resource, and enforcement path must be verified in the actual environment; a platform-level description is not evidence of universal coverage.
Service accounts need boundaries that fit the job
Human authentication controls do not translate directly to unattended services. An integration cannot respond to an MFA prompt every time it runs. Instead, define its legitimate operating pattern: which workload uses the identity, which destinations it needs, what privileges it requires, and who owns changes. These boundaries can expose unnecessary reach that a credential inventory alone would miss.
Suppose a reporting service needs to read one database from a designated application server. Its identity should not also be a convenient general-purpose administrator. Restrictions on unexpected sources or destinations can complement narrower database permissions. The same design discipline applies when an AI workflow uses a service identity: the workflow’s purpose should determine access, rather than inheriting everything the shared account can do.
Behavioral baselines can help identify expected access, but observation alone cannot define authorization. An overprivileged account may have used an unnecessary destination for months. Application owners must distinguish essential dependencies from accumulated convenience before enforcement begins. Document batch cycles, failover behavior, disaster-recovery paths, and emergency access so a new restriction does not silently break an essential process.
Prove the control on a real access path
Begin with a bounded, high-impact workflow, such as administrative access to a server tier or a service account supporting a critical application. Record the identity, authentication mechanism, permitted sources and destinations, policy owner, and enforcement component. This produces a testable design rather than a broad claim that identity security has been deployed.
Test permitted activity and deliberately prohibited activity using controlled accounts. Confirm that a denial reaches the resource, creates useful evidence, and leaves the legitimate workflow operational. Then test exceptions, failover, and recovery. NIST’s implementation findings describe integration gaps and fragmented policy context across real zero trust builds. Owning several capable products does not establish that their signals and decisions work together.
Also test an existing session separately from a fresh authentication. A rule that denies new access may not terminate a session already granted by another system. Endpoint containment, session revocation, credential replacement, and application authorization still have their own roles. The response plan should specify which control performs each action and how success is verified, rather than treating an identity verdict as proof of complete eradication.
For healthcare, manufacturing, financial services, and legal organizations, availability belongs in the same test as security. Define who can authorize an emergency exception, how long it lasts, and how it is removed. Measure progress by the access paths actually restricted, the time required to contain a compromised identity, and the evidence retained for investigation. Alert volume alone cannot show whether an attacker’s next request would succeed.
Microsoft’s report makes the timing problem harder to ignore. Start by reducing unnecessary privilege and mapping the access paths that could turn one compromised account into a wider incident. Place enforceable boundaries on those paths, test them against legitimate operations, and connect them to the response process. A stolen credential should not automatically become permission to move wherever the account has historically been allowed to go.
