Cloud Identity and SSO Token Security: A 30-Day Checklist for Small Businesses
# Cloud Identity and SSO Token Security: A 30-Day Checklist for Small Businesses
Cloud access does not stop at the login screen. After authentication, sessions and access tokens can remain usable until they expire or are revoked. That continuity keeps cloud work practical, but it also means a stolen token or an over-permissioned integration can create risk even when a password and MFA were used correctly. This article provides a 30-day checklist to help small businesses reduce that risk without treating any single control as a cure-all.
Plain-Language Definitions
To address cloud security effectively, it’s essential to understand key terms:
- Password: A secret string of characters used to authenticate a user. While passwords remain a common authentication method, they are increasingly supplemented or replaced by more secure alternatives.
- Multi-Factor Authentication (MFA): A security process requiring users to provide two or more verification factors (e.g., a password and a one-time code) to access an account. MFA significantly reduces the risk of unauthorized access.
- Passkey: A phishing-resistant public-key credential. A private key remains protected by a device or credential provider while the service stores the matching public key. Passkeys can replace passwords for supported sign-ins, but enrollment and account recovery still need protection.
- Session: The authenticated state a service maintains after login. Depending on the service and its configuration, a session can end through expiration, inactivity, sign-out, administrator revocation, or a risk-based policy.
- Access Token: A bearer or proof-bound credential presented to a service to authorize specific access. It is not a hardware security key or one-time code, and possession of a bearer token may be enough to use it until expiration or revocation.
- Single Sign-On (SSO): An arrangement in which applications rely on a central identity provider, allowing a user to authenticate once and reach multiple approved applications. SSO simplifies access, but the identity provider, connected applications, sessions, and tokens all require protection.
- AI Agent Identity: A non-human identity used by an AI-enabled workload to reach systems, data, tools, or APIs. NIST notes that these agents can use signed tokens or assertions, so their privileges, credentials, ownership, logs, and actions need governance [1].
Understanding these terms is foundational to securing cloud environments, where tokens and identities are central to access control.
Current Evidence: Threats and Trends
Recent reports show why identity work must sit beside vulnerability management and incident response. In Mandiant’s 2025 investigations, exploits represented 32% of observed initial infection vectors. Voice phishing rose to 11%, becoming the second most commonly observed vector, while email phishing declined from 14% in 2024 to 6% in 2025. Organizations first detected malicious activity internally 52% of the time, and the global median dwell time was 14 days. Credential stealers represented 9% of observed malware families [2]. These are findings from Mandiant’s investigations, not universal rates for every business, but they support monitoring identities, sessions, and tokens rather than focusing only on email.
The Verizon 2026 Data Breach Investigations Report [5] further underscores the urgency of identity security. 31% of breaches now begin with software vulnerabilities, surpassing stolen passwords as the primary entry point. Ransomware incidents accounted for 48% of breaches, with generative AI amplifying attack techniques. While patching and recovery remain critical, identity work complements these efforts by reducing the attack surface and enabling faster detection.
Why MFA Still Matters
MFA remains a cornerstone of security and should be enabled wherever supported [5]. It is not, however, the last control in the chain. Token theft, malicious OAuth applications, device-code phishing, adversary-in-the-middle attacks, and enrollment abuse can operate after or around the authentication step. Mandiant observed credential stealers in 9% of malware families during its 2025 investigations [2]; Microsoft separately describes infostealers collecting credentials and tokens that can later be sold and reused [4].
The Microsoft Threat Intelligence report [4] highlights patterns where adversaries bypass MFA by leveraging malicious OAuth apps, legacy authentication methods, and device-code phishing. These tactics exploit gaps in identity verification, such as unmonitored third-party applications or insufficient session expiration policies. Even with MFA, businesses must implement additional safeguards, such as short-lived access tokens, continuous monitoring, and conditional access policies.
Okta’s April 2026 O-UNC-066 Campaign
In April 2026, Okta observed a campaign targeting Microsoft 365 passkey enrollment, identified as O-UNC-066 [3]. Attackers used a panel-controlled phishing kit to mimic the passkey enrollment process, tricking users into registering an attacker-controlled identity. The campaign targeted sectors including food/beverage, technology, healthcare, automotive, construction, and aviation.
The phishing kit closely resembled Microsoft’s legitimate enrollment process, making it difficult for users to distinguish between genuine and fraudulent requests. Okta recommends mitigating such attacks through phishing-resistant authenticators, verified help-desk contact methods, managed-device restrictions, lifecycle notifications, and constrained authenticator changes. This incident underscores the need for layered security, as even advanced authentication methods like passkeys are not immune to social engineering.
AI Agents and Non-Human Identities
AI agents are non-human identities that automate tasks or interact with systems, often requiring access to sensitive data or infrastructure. These identities must be treated with the same rigor as human users, adhering to the principle of least privilege. AI agents should be granted short-lived credentials to minimize the impact of potential breaches.
Key considerations for managing AI agent identities include:
- Ownership: Assign clear ownership and accountability for AI agent access.
- Inventory: Maintain an up-to-date inventory of all AI agents and their permissions.
- Logs and Revocation: Enable detailed logging and implement rapid revocation mechanisms in case of compromise.
- Monitoring: Continuously monitor AI agent activity for anomalies or unauthorized access.
NIST puts the operating principle plainly: “No security controls — particularly identity management controls — should be ‘set and forget.’” [1] For AI agents, that means keeping an owner and business purpose on record, limiting each identity to the data and actions it needs, reviewing access, retaining useful logs, and maintaining a tested way to revoke its credentials.
30-Day Checklist: A Week-by-Week Plan
Week 1: Inventory and Baseline Security
Owner: IT Lead
Action: Conduct a comprehensive inventory of all cloud identities, applications, and access tokens.
Evidence: Produce a dated inventory of users, administrators, service accounts, AI agents, APIs, and third-party integrations, with an owner and business purpose for each.
Owner: Security Team
Action: Enable multi-factor authentication (MFA) for human user accounts, beginning with administrators, finance, email, remote access, and cloud-management consoles [5]. For non-human and AI-agent identities, use appropriately scoped application credentials rather than pretending they are people.
Evidence: Export the authentication-method report, list exceptions with an owner and deadline, and verify that no privileged human account relies on a password alone.
Owner: Help Desk
Action: Establish verified help-desk contact methods to prevent phishing attacks.
Evidence: Document approved communication channels and train staff to recognize suspicious requests.
Owner: IT Lead
Action: Pilot passkeys or another phishing-resistant authenticator for administrators and a small user group. Require a separately verified process for enrollment, recovery, and authenticator changes [3].
Evidence: Record the pilot scope, enrollment method, recovery test, exceptions, and the decision on broader rollout.
Week 2: Token and Session Management
Owner: DevOps Team
Action: Implement short-lived access tokens and enforce session expiration policies.
Evidence: Save the approved policy showing token and session lifetimes, revocation behavior, and any documented exceptions.
Owner: Security Team
Action: Conduct a token/session revocation drill to test response times during breaches.
Evidence: Record drill outcomes and refine incident response protocols.
Owner: IT Lead or Security Owner
Action: Enable identity and application logs, choose a retention period the business can support, and alert on risky sign-ins, new authenticators, privilege changes, and suspicious application consent [1].
Evidence: Trigger one safe test event and retain the alert, timestamp, responder, and outcome.
Week 3: Application and OAuth Governance
Owner: IT Lead
Action: Audit OAuth applications and revoke unused or suspicious integrations.
Evidence: Maintain a list of approved applications and monitor for unauthorized access.
Owner: Security Team
Action: Enforce conditional access policies based on user location, device, and risk level.
Evidence: Preserve the policy export and a test showing that a sensitive application denies or challenges an unmanaged device, with a documented emergency-access exception.
Owner: DevOps Team
Action: Secure application secrets and IAM configurations to prevent unauthorized access.
Evidence: Record where each secret is stored, which workload uses it, who owns it, and how it can be revoked; replace exposed or orphaned secrets immediately.
Week 4: Incident Response and Continuous Monitoring
Owner: Security Team
Action: Develop a tabletop response plan for identity-related breaches.
Evidence: Simulate breach scenarios and evaluate response readiness.
Owner: Help Desk
Action: Implement authenticator-change alerts to detect unauthorized access attempts.
Evidence: Monitor alert triggers and refine detection rules.
Owner: HR and IT Lead
Action: Establish a leaver process to revoke access for departing employees or contractors.
Evidence: Document procedures and ensure timely revocation of credentials.
Owner: IT Lead
Action: Maintain a regular patching cadence, prioritize actively exploited and internet-facing vulnerabilities, and test recovery from protected backups. Identity hardening does not replace patching or recovery readiness: Verizon’s 2026 report says 31% of breaches started with software vulnerabilities and 48% involved ransomware [5].
Evidence: Retain the latest patch report and a dated restore-test result, including the owner of any unresolved high-risk item.
Modest Call to Action
Securing cloud identity and SSO token practices requires a proactive, structured approach. While this checklist provides a roadmap, it is essential to tailor strategies to your organization’s unique needs. Consider reaching out to Reliant System for an information security review of this checklist and to explore additional security measures tailored to your business.
Sources
- NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse
- Mandiant M-Trends 2026 Executive Edition
- Okta Threat Intelligence, Vishing actors target Entra passkey enrollment
- Microsoft Threat Intelligence, Microsoft Digital Defense Report 2025 — CISO Executive Summary
- Verizon 2026 Data Breach Investigations Report