A user signs in on Microsoft’s real authentication page. A cloud request presents a valid secret. A remote-support tool carries a valid digital signature. A trusted integrator connects through an approved channel.
Every element can be legitimate. The activity can still be unauthorized.
That distinction runs through recent Cyber Briefs on device-code phishing, exposed service-principal credentials, third-party industrial access, and abuse of remote monitoring and management software. These are different incidents, but they expose the same decision error: organizations often use authenticity as a shortcut for authorization.
Authenticity asks whether an identity, credential, application, or supplier is genuine. Authorization asks whether this specific action is permitted for this identity, purpose, resource, scope, and time. Security breaks down when the first answer is allowed to substitute for the second.
A legitimate mechanism can faithfully execute an illegitimate request.
The interface can be real while the request is hostile
In September, Microsoft described EvilTokens device-code phishing. An attacker initiated an OAuth device-code session, then directed the victim to Microsoft’s genuine sign-in page. If the victim entered the supplied code and completed authentication—including multifactor authentication—the attacker’s session could receive access.
The page was authentic. The user authenticated successfully. Neither fact established that the user understood which session would be authorized.
This is why stronger authentication is necessary but insufficient by itself. An organization must also restrict risky flows, make the requesting application and purpose understandable, and investigate unusual token or device activity. The relevant question is not only “Did the right person authenticate?” It is also “What did that authentication authorize?”
A valid credential may represent invalid intent
Microsoft’s Storm-3168 research described activity involving compromised Azure service principals. Microsoft found that credentials for one principal had appeared in plaintext in a public GitHub issue, although it could not confirm that the exposed secret enabled the observed activity.
The larger lesson is durable: deleting a visible secret does not revoke it. A copied credential may continue to authenticate until it expires, is disabled, or is rotated. The platform can correctly accept the secret while the organization has lost control of who is using it.
Authorization therefore depends on more than possession. Permissions should be limited to the required resources and actions; credentials need owners and lifetimes; exposed secrets require revocation; and use should be evaluated against expected workload behavior.
Signed software can create an unauthorized control channel
On September 29, Microsoft reported phishing campaigns that abused legitimate RMM software. The observed chain installed a signed MSP360 package under deceptive filenames and later added ConnectWise ScreenConnect as a second remote-access path. Microsoft said it did not observe exploitation of ScreenConnect itself.
A digital signature helps establish software provenance and integrity. It does not prove that an installation is approved, that the operator belongs to an authorized tenant, or that the resulting session serves a legitimate business purpose.
That creates a difficult response problem. Blocking every remote-management product can interrupt valid support. Trusting every signed administrative tool can preserve hostile access. The practical control is an approved inventory tied to owners, tenants, operators, devices, and emergency-disable authority—then detection for every instance that falls outside it.
A trusted supplier still needs bounded authority
The same principle extends beyond identity and software. CISA and the FBI’s guidance for organizations working with third-party industrial control system integrators warns that integrators may hold remote access, system knowledge, credentials, and data spanning critical processes.
A supplier can be reputable, contracted, and necessary while holding more access than the current task requires. The relationship establishes a business reason to collaborate; it should not create standing, unreviewed authority.
Owners still need to define permitted systems, access windows, approval conditions, logging, incident notification, continuity duties, and offboarding. A contract delegates work. It does not delegate accountability for the risk decision.
Five questions establish authorization context
NIST’s Zero Trust Architecture rejects implicit trust based solely on network location or asset ownership and treats authentication and authorization as decisions made before access to a resource. That principle becomes practical when every sensitive action can answer five questions:
- Identity: Which person, workload, device, application, tenant, or supplier is acting?
- Purpose: What approved business task should this action perform?
- Scope: Which resources and operations are required—and which are explicitly excluded?
- Time: When should access begin, expire, or require reapproval?
- Control: Who can observe, suspend, revoke, and review the activity?
These questions distinguish “known” from “allowed.” They also produce evidence: approval records, conditional-access policies, scoped roles, credential inventories, session logs, vendor access windows, software allowlists, and revocation tests.
What a smaller organization can do this week
Choose one high-impact access path: cloud administration, remote support, a machine identity, or a critical supplier connection. Then perform a short authorization review.
- Name the internal owner and the person who can revoke access during an incident.
- Compare the approved identity, tool, tenant, resource scope, and schedule with actual logs.
- Remove unused privileges and standing access; rotate any exposed or unowned credential.
- Test the disable or revocation path and confirm monitoring records the action.
- Record the business purpose, exception, expiration, and review trigger.
Do not begin by asking whether the technology or partner is trusted. Begin by asking which actions are authorized now—and what evidence would reveal the difference.
The decision to carry forward
Modern attacks increasingly use genuine infrastructure and ordinary administrative mechanisms. That does not make those mechanisms unsafe by definition. It makes context essential.
Real authentication proves that an authentication event occurred. A valid secret proves that a presented value was accepted. A signature supports software provenance. A contract establishes a relationship. None independently proves that the resulting action is approved.
Legitimate is not the same as authorized.
Authorization requires identity, purpose, scope, time, and a tested way to take access back.
Sources and further reading
- NIST Cybersecurity Framework 2.0
- NIST SP 800-207 — Zero Trust Architecture
- Microsoft — Unmasking EvilTokens
- Microsoft — Storm-3168 and compromised service principals
- Microsoft — Phishing abuse of RMM tools
- CISA and FBI — Third-party ICS integrator considerations
Cyber Brief Weekly explains the cybersecurity changes that matter, the decisions they affect, and the evidence organizations should review next. Cyber Brief is an independent ovniTEK publication aligned to NIST CSF 2.0; it is not an official NIST assessment, certification, or endorsement.