The Curious Node

Category: Cybersecurity

  • Why SSO Tokens Need Their Own Security Plan: Practical Lessons From NIST IR 8587

    Single sign-on makes modern IT usable. It also creates a class of credentials that many organizations do not manage as deliberately as passwords or multifactor authentication.

    On September 15, 2026, the National Institute of Standards and Technology (NIST) published the final version of NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse. Developed with the Cybersecurity and Infrastructure Security Agency (CISA), the report focuses on the identity and access tokens that underpin single sign-on, cloud services, federated identity, and API access.

    The takeaway for IT teams is straightforward: authentication is not finished when a user passes MFA. The token issued afterward may become the credential that grants access for the rest of the session. If that token is stolen, forged, replayed, or accepted by the wrong service, an attacker may gain access without repeating the original login.

    What changed in the final guidance

    NIST’s September 15 announcement says the final report expands the December 2025 draft in several useful ways. It makes the cryptographic-key recommendations more outcome-focused, adds detail about key use, protection, and storage, and introduces high-level considerations for artificial intelligence agents and post-quantum cryptography. It also points readers to additional standards and mechanisms for token revocation and security-event sharing.

    This is a final NIST Interagency Report, not a proposed rule. It is written primarily for federal agencies and cloud service providers, but NIST explicitly notes that the practices can benefit organizations more broadly. For school districts, local governments, nonprofits, and private-sector IT teams, it is best treated as authoritative implementation guidance—not as a guarantee of compliance or a substitute for requirements that apply to a particular organization.

    Seven practical reviews to conduct now

    1. Inventory every trust relationship

    Document which systems issue tokens, which systems validate them, which identity providers are trusted, and which applications accept each token type. Include SaaS platforms, internal applications, service accounts, APIs, automation platforms, and machine-to-machine integrations. An incomplete inventory makes it difficult to know where a compromised token could be reused.

    2. Protect signing keys as critical infrastructure

    Token security depends heavily on the keys used to sign and verify tokens. Review how keys are generated, stored, distributed, rotated, and revoked. Prefer managed or hardware-backed protection where appropriate, tightly limit administrative access, and make sure emergency rotation is documented and tested. The report devotes a full section to cryptographic key management, including generation, storage, rotation, revocation, and compromise recovery.

    3. Validate more than the signature

    A valid signature does not automatically mean a token should be accepted. Applications should verify the expected issuer and audience, enforce approved algorithms, check time-related claims, and reject tokens intended for another service. Validation rules should be consistent across custom applications, vendor products, gateways, and APIs.

    4. Limit token lifetime and plan for fast revocation

    Short-lived access tokens reduce the window in which a stolen token can be abused. Refresh tokens require stronger protection because they can extend that access. Review token and session lifetimes against actual operational needs, then confirm that administrators can revoke access quickly when an account, device, application, or key is compromised.

    5. Monitor token use, not only login events

    Centralize identity-provider, application, cloud, and API logs so the security team can follow a session after authentication. Look for unusual audiences, locations, devices, refresh patterns, token reuse, impossible travel, and access that continues after a role change or account disablement. NIST IR 8587 specifically includes continuous monitoring among its core consumer practices.

    6. Make shared responsibility explicit

    Cloud providers secure part of the token lifecycle; customers still control configuration, integration, monitoring, and access decisions. The report separates recommendations for service providers and service consumers. Contracts, architecture diagrams, and incident-response plans should clearly state who rotates keys, retains logs, detects misuse, revokes sessions, communicates incidents, and verifies recovery.

    7. Include workloads and AI agents

    NIST notes that the guidance applies when AI agents use signed tokens to reach systems, data, tools, or APIs. The report is not a complete guide to AI-agent security, and NIST says guidance in this area is still evolving. Even so, the immediate lesson is useful: give each workload or agent a distinct identity, minimize its privileges and token audience, avoid unnecessary long-lived credentials, and ensure its activity can be traced and revoked independently.

    A useful tabletop exercise

    Ask a simple question: If an attacker stole a valid token from one of our most connected applications today, how quickly could we identify its reach and invalidate it?

    The answer should identify the issuing system, accepted audiences, token lifetime, refresh path, revocation method, relevant logs, response owner, and downstream dependencies. If several teams or vendors must be contacted before those facts are known, the organization has found a valuable improvement opportunity without waiting for an incident.

    The bottom line

    SSO remains one of the best ways to improve usability and centralize access control, but the convenience can obscure the credentials moving behind it. NIST IR 8587 gives IT and security teams a practical framework for treating tokens, assertions, and their signing keys as first-class security assets.

    For most organizations, the best first step is not a new product. It is a short inventory followed by a focused review of validation, key management, token lifetime, revocation, logging, and provider responsibilities. That work makes existing identity investments substantially more defensible.

    This article provides general cybersecurity information and is not legal or compliance advice.

    Primary sources

  • Texas Public-Sector AI Rules Are in Force: What IT Leaders Should Do Before August 31

    Texas public-sector organizations now have two related—but distinct—artificial intelligence responsibilities to manage: annual AI-awareness training and a broader governance framework for government AI systems. With the Texas Department of Information Resources (DIR) setting August 31 as the annual date for government entities to certify training compliance, late August is a useful checkpoint for both requirements.

    The most important legal-status update is that the rules first proposed in November 2025 are no longer merely proposals. DIR’s final rules in 1 Texas Administrative Code Chapters 218 and 219 were adopted with an effective date of March 18, 2026, according to the March 13, 2026 Texas Register adoption notice. Chapter 219 establishes an AI code of ethics and minimum governance standards for state agencies and local governments.

    The August 31 training deadline

    Texas Government Code Sections 2054.5191 and 2054.5193 created an annual certified AI-awareness training program for covered state and local government personnel. DIR’s current public-sector AI awareness training page says government entities must certify compliance annually by August 31 using DIR’s reporting form.

    For state agencies, the requirement generally covers employees who use a computer for at least 25 percent of their duties and elected or appointed officers. For local governments, it generally covers employees and officials who meet the 25-percent computer-use threshold and have access to a government computer system or database. DIR also explains an important K-12 distinction: only a school district’s cybersecurity coordinator is specifically required to complete the annual AI training; the district determines any additional covered employees in coordination with that official.

    DIR provides a certified training option at no cost, but it does not track completion or issue certificates. Employers therefore remain responsible for keeping their own completion records. DIR also says entities may use any tracking method they choose and should not submit individual training records or employee certificates with the annual certification.

    Training is only one part of the new framework

    The annual awareness course should not be mistaken for the full AI-governance program. Under the adopted Chapter 219 rules, state agencies and local governments must adopt the state AI code of ethics and follow its principles when procuring, developing, deploying, or using AI systems. Those principles cover human oversight, fairness, accuracy, transparency, redress, privacy, security, and accountability.

    The rules impose additional controls when an organization develops, procures, deploys, or uses a heightened scrutiny AI system—an AI system intended to autonomously make, or serve as a controlling factor in making, a consequential decision. The final Texas Register text requires state agencies and local governments to designate an AI Risk Officer and establish a process for identifying and inventorying heightened-scrutiny systems.

    Before deploying such a system—and again after a material change—the organization must complete a written risk assessment. The assessment must address known security risks and mitigations, performance metrics related to accuracy and operational efficiency, and transparency concerning algorithms, training data, inputs, and outputs. The AI Risk Officer must review the assessment and approve or deny deployment. Relevant documentation must be retained under the applicable records-retention schedule.

    Chapter 219 also requires acceptable-use policies and role-appropriate risk training for employees or contractors who access, use, or manage heightened-scrutiny systems. Contracts for vendor-deployed heightened-scrutiny AI must require the vendor to implement the NIST Artificial Intelligence Risk Management Framework or a comparable standard.

    A practical readiness checklist

    1. Confirm the covered population. Apply DIR’s role, system-access, and computer-use criteria rather than assigning the course based only on job title.
    2. Complete and document certified training. Keep an internal roster or equivalent evidence because DIR’s free course does not track completion.
    3. Submit the annual certification. Use the reporting link on DIR’s current training page by August 31.
    4. Name the AI Risk Officer and inventory higher-risk uses. Look beyond standalone chatbots; consider AI embedded in hiring, benefits, eligibility, discipline, fraud detection, public services, and other consequential workflows.
    5. Review policies and contracts. Check acceptable-use rules, privacy controls, human-review procedures, incident escalation, vendor transparency, risk-assessment obligations, and records retention.

    The NIST connection is still evolving

    Texas explicitly anchors its governance approach to the NIST AI RMF. NIST states that AI RMF 1.0 is currently being revised, and its newly final NIST IR 8578, published August 3, 2026, summarizes governance and operational issues raised during development of a Cybersecurity Framework Community Profile for AI. IR 8578 is a workshop summary—not a new compliance standard—but it reinforces the value of connecting AI governance with existing cybersecurity processes.

    The immediate priority is straightforward: complete and certify required training by August 31, while treating that course as the beginning—not the end—of an operational AI-risk program.

    This article provides general information and is not legal advice. Organizations should review the current statutes, rules, and DIR guidance and consult qualified counsel regarding their specific obligations.

    Primary sources

  • How Artificial Intelligence Is Changing Cybersecurity in 2026

    How Artificial Intelligence Is Changing Cybersecurity in 2026

    Artificial intelligence is reshaping cybersecurity from both sides of the conflict. Security teams are using AI to analyze alerts, identify unusual behavior, and respond faster. At the same time, attackers are using the same technology to create more convincing deception, accelerate reconnaissance, and experiment with new forms of malware.

    In 2026, the most important change is not that AI has replaced cybersecurity professionals. It has not. The deeper change is that AI is becoming a force multiplier: it increases the speed, scale, and reach of both defenders and attackers. Organizations that understand this shift can gain an advantage, while those that treat AI as simply another software tool may introduce risks they cannot easily see.

    AI is helping defenders make sense of overwhelming data

    Modern networks generate enormous volumes of information from endpoints, cloud platforms, identity systems, email gateways, and applications. Human analysts cannot examine every event individually. AI-assisted security tools can help by finding patterns, connecting related signals, prioritizing alerts, and summarizing an incident for investigation.

    This can reduce time spent on repetitive triage and allow experienced analysts to focus on decisions that require context and judgment. AI can also support threat hunting, malware analysis, vulnerability prioritization, and the creation of detection rules. Used carefully, it becomes a practical assistant rather than an autonomous replacement for a security team.

    The word carefully matters. An AI-generated conclusion can be incomplete or wrong, especially when the underlying data is poor. High-impact actions—such as isolating systems, disabling accounts, or blocking business processes—should remain observable, reversible, and subject to appropriate human approval.

    Social engineering is becoming faster and more convincing

    Phishing has always relied on human trust. Generative AI makes it easier to produce polished messages, translate them into multiple languages, imitate a particular writing style, and customize a lure using publicly available information about a company or employee.

    Microsoft’s 2025 Cyber Signals report on AI-powered deception described how attackers use AI tools to build detailed target profiles and create convincing fraudulent content. The result is not necessarily a completely new kind of crime. Instead, familiar scams can be produced more quickly, cheaply, and at greater scale.

    Deepfake audio and video add another layer of risk. A message that appears to come from an executive, vendor, or family member may no longer be trustworthy simply because the voice or face seems familiar. Organizations need verification procedures that do not depend on appearance alone, particularly for payments, password resets, confidential files, and changes to account access.

    Attackers are experimenting with AI-assisted malware

    Threat actors are also exploring ways to use AI during technical attacks. Google Threat Intelligence reported experimental malware called PROMPTFLUX that queried an AI service for obfuscation techniques intended to help it evade static detection. Google emphasized that the observed sample was experimental and did not demonstrate the ability to compromise a victim by itself, but the research shows the direction in which attacker experimentation is moving.

    Microsoft later documented SesameOp, a backdoor that misused a legitimate AI service as a covert command-and-control channel. The case did not involve an AI model autonomously conducting an attack. It demonstrated something more immediate: attackers can abuse trusted AI infrastructure as part of conventional malware operations.

    These examples suggest that defenders should monitor how AI services are accessed from their environments. Unexpected API calls, unusual service accounts, unapproved AI tools, and abnormal data transfers may become increasingly important investigative signals.

    AI systems create their own attack surface

    AI is not only a security tool or an attacker tool. It is also a system that must be secured. Models, training data, prompts, plugins, external tools, retrieval databases, and user permissions can all create paths for abuse.

    The National Institute of Standards and Technology’s Adversarial Machine Learning taxonomy organizes important risks such as evasion, data poisoning, privacy attacks, and generative-AI misuse. These risks can affect different stages of an AI system’s life cycle. For example, an attacker might manipulate data used by a model, craft inputs that cause unsafe behavior, attempt to extract sensitive information, or misuse a model’s legitimate capabilities.

    This means an organization cannot secure an AI application by looking only at the model. It must also protect the surrounding data, identities, APIs, software dependencies, and business processes.

    Cybersecurity strategy is becoming AI-aware

    NIST’s developing Cyber AI Profile frames the challenge around three connected priorities: securing AI system components, using AI to improve cyber defense, and thwarting AI-enabled attacks. That is a useful way to think about the subject because no single product can address all three.

    Collaboration will also matter. The Cybersecurity and Infrastructure Security Agency’s AI Cybersecurity Collaboration Playbook encourages structured information sharing about AI-related incidents and vulnerabilities. As technologies change quickly, defenders benefit when lessons learned by one organization can improve resilience across many others.

    Seven practical actions organizations can take

    1. Inventory AI use. Identify approved and unapproved AI tools, the data they access, their owners, and the business processes they influence.
    2. Strengthen identity security. Use phishing-resistant multifactor authentication where possible, limit privileges, and review service accounts and API credentials.
    3. Verify sensitive requests through a second channel. Payments, credential changes, and confidential disclosures should not rely only on email, voice, or video.
    4. Protect AI data and connections. Control access to training data, retrieval systems, prompts, plugins, and external tools. Treat inputs and generated outputs as potentially untrusted.
    5. Keep humans responsible for high-impact decisions. Define which automated actions require review, and make important actions traceable and reversible.
    6. Monitor AI activity. Log model access, API usage, tool calls, administrative changes, and unusual data movement so that incidents can be investigated.
    7. Update incident-response plans. Practice scenarios involving deepfake impersonation, compromised AI credentials, poisoned data, and malicious use of connected AI agents.

    The human advantage still matters

    AI will continue to change the economics of cybersecurity. It can help defenders process information faster, but it can also help attackers generate content and test ideas at a scale that was previously difficult to achieve.

    The strongest response is not to avoid AI or to trust it without question. It is to combine useful automation with sound security fundamentals: clear ownership, strong identity controls, protected data, careful monitoring, practiced response procedures, and informed human judgment. In 2026, organizations that build those foundations will be better prepared for both the opportunities and the risks that AI brings.

    Sources and further reading