The Endpoint Passed. The Transaction Failed: Test APIs as Business Systems

Posted on November 11, 2026 by Brent Huston

The gateway accepts the token.

The request matches the schema. The endpoint rejects malformed input. Rate limits are enabled. Automated scans return no critical findings. Each API operation appears to work as designed.

Then the business transaction fails.

A user applies the same one-time credit twice through concurrent requests. A partner calls the final step before the required approval. A mobile client changes an object identifier and acts on another customer’s record. A cancellation arrives after fulfillment has started but still triggers a full refund. A retry repeats an external payment because the first result was uncertain.

The individual requests may be technically valid.

The sequence, authority, timing, or business result is not.

That is the gap between endpoint security and transaction assurance.

API security should prove that the complete business transaction preserves its intended rules across actors, objects, states, sequence, timing, retries, and failure—not merely that individual endpoints reject malformed requests.

APIs Implement Business Decisions

An API is not only a technical interface.

It may approve a payment, reserve inventory, change ownership, create an account, release data, issue a refund, alter a configuration, assign a role, trigger a shipment, or call another provider.

The National Institute of Standards and Technology’s updated API protection guidance describes modern enterprise systems as relying on families of APIs to support organizational business processes. The March 2026 update adds API risks and recommended controls organized by lifecycle stage.

That framing matters.

If several APIs jointly implement a business process, assurance cannot stop at the boundary of each endpoint. The organization must also establish whether the combined behavior preserves the business decision.

Consider a simple approval workflow.

One endpoint creates a request. Another attaches supporting data. A third records an approval. A fourth executes the action. Each endpoint can authenticate the caller, validate its input, and return the expected status code.

The workflow can still be unsafe if:

The requester can also approve.
The approval applies to a different version of the request than the one executed.
The execution step can be called before approval.
A completed approval can be replayed.
Two requests can race and both consume the same limit.
A web client enforces a restriction that the underlying API does not.
A trusted downstream service accepts more authority than the original user possessed.

The security property lives in the relationships among the calls.

Start With the Business Invariant

Before testing the workflow, state what must remain true.

Call this the business invariant.

Examples include:

Only the owner of a record, or an explicitly authorized delegate, may modify it.
A requester may not approve their own high-value transaction.
A one-time credit may be issued only once to an eligible customer.
A payment may execute only for the amount, destination, and order the user approved.
A completed or expired step may not be replayed.
Inventory may not fall below the permitted threshold.
A refund may not exceed the amount actually settled.
A tenant administrator may act only within the tenant they administer.

These statements are more useful than “the API requires authentication.”

Authentication identifies an actor. The invariant defines what that actor may cause under specific business conditions.

The OWASP Top 10:2025 keeps broken access control in the first position. Its guidance includes enforcing record ownership, applying business limits in the domain model, and testing functional access control through unit and integration tests.

The OWASP API Security Top 10 adds another important dimension: an endpoint can expose a sensitive business flow whose excessive or automated use harms the business even when the operation is available by design.

The first question is therefore not:

Does the endpoint work?

It is:

What must remain true when this business transaction is performed, repeated, interrupted, reordered, or attempted by the wrong actor?

Build the Transaction Security Model

A useful transaction model has seven parts.

1. Invariant: What must never become false?

Write the rule in business language.

Avoid vague statements such as “prevent fraud” or “enforce authorization.” Name the protected result: who may act, on which object, under what conditions, how often, within which limits, and with what required approvals.

If the team cannot state the invariant, the test plan will inherit the same ambiguity.

2. Actors: Who or what can participate?

List every relevant human and machine identity.

Include customers, employees, administrators, delegates, service accounts, partners, background jobs, mobile applications, web applications, support tools, automation, and downstream providers.

Do not assume that two callers with the same role have the same authority. Ownership, tenant, relationship, device, location, transaction value, approval history, and current risk state may all change the decision.

OWASP’s authorization guidance recommends defining trust boundaries, user types, resources, operations, and the relationships among them during design, then creating tests to prove that those permissions are enforced.

3. Objects: What is being read, changed, or transferred?

Identify the accounts, records, funds, orders, documents, roles, devices, configurations, entitlements, and other objects involved.

Then test ownership and relationship explicitly.

A user may be authorized to call an endpoint without being authorized to act on every object the endpoint can reach. OWASP identifies this as broken object-level authorization: the function is available, but the requested object falls outside the caller’s authority.

4. States: Which conditions change what is allowed?

Define the transaction states and the valid transitions among them.

A request might move from draft to submitted, reviewed, approved, executing, completed, disputed, reversed, or expired. The exact names matter less than making the transitions explicit.

The server should validate the current state before accepting the next action. The client interface should not be the only mechanism preventing a user from skipping ahead, returning to a completed step, or changing a transaction after approval.

OWASP’s business-logic security guidance recommends enforcing workflows as explicit state machines, rejecting replays of completed steps, expiring partial states, and testing the intended business process rather than relying on the user interface to preserve order.

5. Paths: Which interfaces can reach the same business action?

Map every route to the outcome.

The same action may be available through a web application, mobile API, partner integration, administrative console, GraphQL operation, webhook, batch job, legacy version, support function, or internal service.

Controls must be consistent across those paths.

A restriction in the web interface does not protect a directly callable API. An authorization check in a current endpoint does not protect an older version. An administrative function placed beside ordinary functions still requires an explicit decision for the caller. OWASP’s guidance on function-level authorization recommends reviewing the complete role and group hierarchy and denying access by default for every function.

6. Timing: What changes when requests overlap, repeat, or arrive late?

Test concurrency, retries, replay, cancellation, timeout, and partial failure.

Many business rules have the form “check a condition, then act.” That creates a risk when two requests can observe the same valid condition before either records the result.

Test whether:

Two requests can redeem the same benefit.
A retry repeats a non-idempotent external action.
A cancellation races with fulfillment or settlement.
An expired approval remains usable.
A partial transaction can be resumed after its assumptions changed.
A delayed webhook reverses a newer decision.
A client changes parameters while reusing an idempotency key.

These are not malformed-request tests.

They are consistency tests.

7. Evidence: What proves the invariant held?

A successful status code is not enough.

Preserve the evidence needed to reconstruct the transaction:

The authenticated actor and effective authority.
The object, owner, tenant, and relevant relationships.
The transaction state before and after the action.
The policy or business rule evaluated.
The significant values approved by the user or system.
The request, decision, downstream action, and final outcome.
The retry, replay, or idempotency identifiers.
The reason for a denial, exception, override, or reversal.

The purpose is not to log every secret or duplicate sensitive data.

It is to retain enough trustworthy evidence to determine whether the business rule was enforced and to investigate when the outcome is disputed.

Test Valid Data in the Wrong Context

Traditional negative testing often begins with invalid input.

That remains useful. APIs should reject malformed, oversized, unexpected, and dangerous data.

Business-transaction testing adds a different form of negative test:

Use valid data, valid identities, and valid functions in an invalid business context.

Try the correct request with:

The wrong owner.
The wrong tenant.
The wrong role.
The wrong relationship.
The wrong transaction state.
The wrong order of operations.
A changed amount or destination after approval.
A repeated one-time action.
Two simultaneous calls.
An alternate client or API version.
A delayed or duplicated downstream message.
A valid credential whose business authority has changed.

This is where the gap between technical permission and business permission becomes visible.

Keep the Existing Controls

This model is not an argument against gateways, authentication, schema validation, rate limits, automated scanning, code analysis, or endpoint-level testing.

Those controls answer essential questions.

They can establish that a caller presented an accepted credential, a request matched the contract, an input avoided a known weakness, or an endpoint enforced a local policy.

They cannot independently establish that the complete transaction preserved ownership, separation of duties, state, value, timing, and business intent across every participating interface.

Use the controls together:

Define the invariant during design.
Enforce authorization and state on the server.
Test each endpoint’s local requirements.
Test the complete transaction across roles and objects.
Test ordering, replay, concurrency, retries, and failure.
Monitor the business outcome, not only the request volume.
Turn each discovered abuse path into a regression test.

The objective is not to replace automation with manual testing.

It is to give automation better rules to prove.

What Security Leaders Should Do This Week

Choose one API-supported transaction involving money, sensitive data, privilege, inventory, approval, or an irreversible action.

State the invariant. Write one sentence describing what must remain true.
Map the transaction. Identify the actors, objects, states, endpoints, clients, and downstream services involved.
Build the authority matrix. Record who may perform each action on which objects and under which conditions.
Test one sequence failure. Skip a step, reorder two steps, replay a completed step, or modify the transaction after approval.
Test one timing failure. Submit simultaneous requests, repeat an uncertain operation, or race cancellation against completion.
Verify the evidence. Confirm that logs and records show the actor, authority, state, decision, and final outcome without exposing unnecessary sensitive data.
Create the regression. Add the discovered business rule and abuse case to design requirements, automated tests, and release criteria.

Then ask a direct question:

Can we prove that this business transaction stays within its intended limits when every individual request is technically valid?

If the answer is unclear, the endpoint tests are not the end of the assessment.

They are the beginning of the transaction test.

Put Transaction-Level Assurance Into Practice

MicroSolved, Inc. can help organizations evaluate application, API, and mobile workflows where authorization, business logic, and transaction integrity matter.

Useful consulting engagements may include:

Identifying high-consequence business transactions and their required invariants.
Threat modeling actors, objects, roles, tenants, states, and downstream dependencies.
Testing object-level and function-level authorization across web, mobile, administrative, partner, and legacy paths.
Evaluating sequence, replay, concurrency, idempotency, cancellation, rollback, and partial-failure behavior.
Reviewing API design, gateways, schemas, logging, monitoring, and abuse controls as one assurance system.
Converting findings into prioritized mitigations, regression tests, and practical release criteria.
Supporting targeted assessments for payments, approvals, account recovery, data access, administrative actions, and other sensitive workflows.

To discuss an application or API security review, contact MicroSolved at info@microsolved.com or +1.614.351.1237.

Relax. We’re on watch.

AI tools were used as a research assistant for this content, but human moderation and writing are also included.

Before You Ask the Vendor: Build a Passive Due Diligence Layer

Posted on November 4, 2026 by Brent Huston

The vendor has already made the shortlist.

The business owner wants the contract signed this month. Procurement has scheduled the demonstration. The implementation team has started discussing integrations. Then security sends the questionnaire.

At that point, the assessment may still identify important problems. It may also be working against momentum that has already become a business constraint.

There is another problem.

The first substantial evidence often comes from the vendor itself: a questionnaire, policy packet, audit report, architecture diagram, penetration-test summary, or carefully prepared response from the sales and assurance teams.

That evidence matters. It is not the only evidence that matters.

The practical lesson is straightforward:

Third-party risk should begin with passive, evidence-based due diligence before direct outreach, then use vendor-supplied evidence to resolve what outside-in research cannot answer.

Due Diligence Should Start Before the Questionnaire

In July 2026, NIST finalized SP 1326, the Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide. It defines due diligence as researching and verifying available, pertinent information about a supplier or product so that an acquirer can make informed decisions about new acquisitions or existing systems.

The guide makes an especially useful distinction.

Basic due diligence uses desktop research and publicly available information without contacting the supplier. Enhanced due diligence adds commercial datasets, proprietary sources, and supply-chain illumination tools. NIST recommends choosing the level of effort based on available resources and acquisition criticality, and validating findings against multiple sources when possible.

That creates a useful sequence:

Learn what can be established independently.
Identify what remains uncertain.
Ask the supplier targeted questions.
Validate the answers according to the consequence of being wrong.

The questionnaire becomes more valuable because it is no longer trying to discover everything from a blank page.

Vendor-Supplied Evidence and External Evidence Answer Different Questions

A supplier is usually the best source for information that is not externally observable.

That may include internal governance, access-control design, backup and recovery procedures, secure development practices, personnel controls, incident-response responsibilities, data flows, subcontractor oversight, and evidence from private testing or audits.

Outside-in research answers a different set of questions.

It can help establish:

Which legal entity the organization is actually evaluating.
Which domains, public services, certificates, applications, repositories, and infrastructure appear related to that entity.
Where public-facing operations and important dependencies are located.
Whether ownership, leadership, hosting, technology, or product-support conditions have changed.
Whether public records identify breaches, sanctions, exclusions, litigation, regulatory action, exposed credentials, obsolete technology, or other conditions relevant to the decision.
Which sub-tier providers or shared dependencies may create concentration risk across several suppliers.

Neither view is complete.

A clean external footprint does not prove that internal controls are effective. A strong audit report does not prove that every externally visible asset belongs to the assessed boundary, is currently maintained, or was included in the audit. A questionnaire response may be accurate when submitted and stale six months later. An external observation may be technically correct and still attributed to the wrong subsidiary, legacy domain, shared host, or acquired product.

The goal is not to choose between attestation and observation.

It is to reconcile them.

Start With the Decision, Not the Data

Passive research can produce a large amount of information very quickly. Without a decision boundary, that becomes another collection problem.

Begin by writing down the decision the research must support:

Should this supplier enter the shortlist?
What diligence is required before contract signature?
What conditions should appear in the agreement?
Does a proposed acquisition need deeper technical review?
Has an existing critical supplier changed enough to require reassessment?
Which vendors deserve scarce assessment time first?

Then define the consequence of supplier failure.

The final NIST CSF 2.0 C-SCRM Quick-Start Guide recommends that suppliers be known and prioritized by criticality and that requirements be scaled to the supplier’s importance and the risk presented by the product or service. The updated NIST SP 800-161 Revision 1 likewise treats supply-chain risk as an organization-wide risk-management problem rather than a procurement checklist.

Useful criticality questions include:

What sensitive data will the supplier store, process, transmit, or be able to reach?
Which production systems, identities, networks, facilities, or business processes will it influence?
How quickly could the organization replace the service?
What would happen if the supplier became unavailable, untrustworthy, or legally unusable?
Which customers, regulators, safety functions, financial processes, or strategic transactions depend on it?

The deeper the dependency, the stronger the evidence requirement should become.

Build the Passive Evidence Record in Six Steps

A passive due diligence layer should produce a defensible record, not a mysterious score.

1. Resolve the identity

Start with the legal name, ownership structure, primary domains, relevant subsidiaries, product names, acquisitions, and known operating locations.

This sounds administrative. It is one of the most important technical controls in the process.

If the assessed entity is ambiguous, every later observation can be misattributed. A certificate, exposed service, breach record, code repository, or hosting relationship may belong to a parent, subsidiary, former brand, customer tenant, reseller, or unrelated organization with a similar name.

Record aliases and relationships explicitly. Do not quietly merge them into one profile.

2. Map the relevant external footprint

Collect only the evidence needed for the decision and allowed by policy, law, and the organization’s rules of engagement.

Depending on scope, that may include public corporate records, regulatory and exclusion lists, company disclosures, breach notices, domain and certificate data, public service metadata, published application information, public repositories, vulnerability and end-of-life information, hosting relationships, and identified supply-chain dependencies.

NIST SP 1326 organizes due diligence into five research categories: foreign ownership, control, or influence; provenance; resilience; foundational cyber practices; and supply-chain tiers. Those categories are broader than an internet scan. They connect technical exposure to ownership, location, operational reliability, product history, and dependency structure.

3. Separate observation, inference, and decision

Every material item should identify what kind of statement it is.

Observation: A public certificate record associates a hostname with a domain. A regulator published an enforcement action. A vendor announced an acquisition. A public repository contains a supported product’s code or documentation.

Inference: The asset may be part of the supplier’s current production environment. The acquisition may change service delivery. The observed version may indicate delayed maintenance. Several vendors may depend on the same provider.

Decision: Require clarification. Expand technical testing. Add a contract condition. Raise the monitoring frequency. Accept the risk. Remove the supplier from consideration.

Treating inference as fact creates false confidence. Treating observation as a decision allows an automated finding to replace accountable judgment.

4. Corroborate, timestamp, and preserve provenance

For each consequential finding, record:

The source and collection date.
The entity or asset to which it is attributed.
The observed fact.
The confidence in the attribution.
Corroborating or conflicting sources.
The age and likely shelf life of the information.
The business or technical decision it may affect.
The owner and next review date.

NIST SP 1326 specifically recommends validating findings through multiple sources when possible. It also warns that age, recurrence, severity, and current mitigation affect whether historical information remains relevant.

A ten-year-old incident may show organizational history. It may not describe current control performance. A DNS change from yesterday may be current. It may also be routine migration activity with no security significance.

Evidence needs context.

5. Convert findings into targeted supplier requests

The passive record should make the questionnaire shorter and sharper.

Instead of asking, “Do you manage vulnerabilities?” ask:

We identified a public service that appears to support this product. Is it inside the service boundary, and how is it maintained?
Your documentation names one hosting provider while current external evidence suggests another. What changed, and which subprocessor terms apply?
We found a product version with a published end-of-support date. Is that version still used for our proposed service?
Your ownership or operating-location data changed during the review period. Does that affect data access, support, resilience, or contractual commitments?
Several critical suppliers appear to rely on the same sub-tier provider. What continuity options exist if that provider fails?

These are not accusations.

They are requests to reconcile evidence.

The response can confirm attribution, explain a harmless condition, identify a stale record, disclose a compensating control, or reveal a real gap. Every outcome improves the decision record.

6. Define the refresh triggers before the contract is signed

Third-party risk does not become static after approval.

NIST SP 1326 recommends considering a continuous monitoring process, including when information should be refreshed and how reports will be updated. For banking organizations, the joint Interagency Guidance on Third-Party Relationships similarly describes ongoing monitoring throughout the relationship, scaled to risk and adjusted when the type or level of risk changes.

Useful reassessment triggers include:

A merger, acquisition, divestiture, or material ownership change.
A new hosting, cloud, identity, payment, data, or support dependency.
A material breach, outage, regulatory action, or public allegation.
A change in exposed services, certificates, domains, applications, or infrastructure.
Product end-of-life, loss of support, or a major technology transition.
Expansion into new data, systems, locations, business processes, or customer populations.
Repeated failure to explain or remediate a material inconsistency.

Calendar reviews still have value. Event-driven reviews catch change closer to the moment it matters.

Passive Does Not Mean Uncontrolled

An outside-in assessment needs its own governance.

Public availability does not make every collection or use appropriate. The process should define permitted sources, prohibited actions, privacy handling, data retention, evidence classification, analyst access, attribution standards, supplier communication, and escalation paths.

Passive research should not quietly become intrusive testing.

Do not bypass access controls, authenticate without authorization, exploit systems, create load, or probe a supplier beyond the approved rules of engagement. If a finding requires active validation, obtain authorization and move it into a separate assessment plan.

The record can also become sensitive when aggregated. A collection of public facts may reveal relationships, vulnerabilities, acquisition interests, concentration risk, or strategic dependencies that no single source discloses. Protect the resulting analysis according to its consequence, not merely according to the public status of its ingredients.

Measure Decision Quality, Not Finding Volume

A large passive-monitoring feed can look productive while leaving the organization unable to act.

More useful measures include:

Percentage of critical suppliers with identity and ownership resolved before direct outreach.
Percentage of proposed critical relationships with a passive evidence brief before shortlist or contract approval.
Percentage of consequential findings corroborated by more than one source.
Percentage of material observations with explicit attribution confidence and evidence age.
Time from supplier nomination to an initial decision-ready brief.
Percentage of passive findings converted into a targeted question, validation step, contract requirement, monitoring trigger, or documented disposition.
Number of critical suppliers sharing the same material sub-tier dependency.
Time from a material external change to owner acknowledgement and reassessment.
Percentage of unresolved high-consequence assumptions accepted by a named risk owner.

One measure deserves special attention:

How much supplier risk can you explain before you ask the supplier to explain itself?

The objective is not suspicion.

It is preparation.

What Security Leaders Should Do This Week

Choose one proposed or existing supplier that supports a high-consequence business process.

Write the decision. Define whether the work supports shortlisting, contracting, renewal, monitoring, M&A diligence, or escalation.
Set the criticality. Record the data, access, operational dependency, replacement difficulty, and consequence of supplier failure.
Resolve the entity. Confirm the legal name, ownership, domains, subsidiaries, products, and relevant locations.
Build a passive evidence brief. Use approved public and commercial sources to examine provenance, resilience, foundational cyber practices, and material supply-chain relationships.
Label the reasoning. Separate observed fact, analyst inference, unresolved question, and risk decision.
Ask only what the evidence cannot answer. Turn inconsistencies and unknowns into targeted supplier requests and validation steps.
Define the refresh rule. Set calendar and event-driven triggers, a named owner, and a response path for material change.

A questionnaire is useful.

An audit report is useful.

A vendor meeting is useful.

They become more useful when the organization arrives knowing what it has already observed, what it still needs to learn, and which decision the evidence must support.

Do the quiet research first.

Then ask better questions.

Put SilentTiger to Work Before the Questionnaire

MicroSolved, Inc. positions SilentTiger™ as a passive vendor, supply-chain, and external-exposure monitoring capability for due diligence, third-party risk, M&A, and pre-approach research.

MSI can help organizations:

Build decision-focused passive due diligence profiles for prospective and existing suppliers.
Map externally observable assets, dependencies, ownership, provenance, and change indicators.
Corroborate findings across public and authorized commercial sources.
Separate observation from inference and translate evidence into targeted supplier questions.
Prioritize deeper assessment according to supplier criticality and business consequence.
Establish repeatable monitoring triggers for material external change.
Support M&A, supply-chain, vendor-risk, and pre-engagement research without treating passive evidence as proof of internal control effectiveness.

To discuss SilentTiger or a passive vendor-risk assessment, contact MicroSolved at info@microsolved.com or +1.614.351.1237.

Relax. We’re on watch.

AI tools were used as a research assistant for this content, but human moderation and writing are also included.

The Dangerous Moment Is the State Change: Security Testing for Connected Devices

Posted on October 27, 2026 by Brent Huston

The firmware image passes static analysis.

The administrative interface survives a penetration test. The network scan shows only approved services. The mobile application and cloud API have been reviewed. The device enters production with a clean report.

Then the device changes state.

A technician enters maintenance mode. An update loses power halfway through installation. A factory reset prepares the device for a new owner. A recovery process restores an older image. A field engineer connects to a local service interface. A retired device remains registered to a cloud account.

The controls that worked during normal operation may not work the same way during any of those transitions.

That is the testing gap.

Connected-device security is usually evaluated as a collection of components and attack surfaces: firmware, hardware, network services, wireless interfaces, applications, APIs, and cloud infrastructure. Each view matters. None of them, by itself, proves that the product preserves its intended trust state when it is provisioned, updated, interrupted, repaired, reset, transferred, recovered, or retired.

The practical lesson is straightforward:

Device security assurance should test the transitions that change authority, software, data, and operating mode—not only the device’s steady state.

A Connected Product Has More Than One Security State

A connected device is not simply secure or insecure.

It moves through states.

The lifecycle may include manufacturing, initial provisioning, normal operation, degraded operation, maintenance, software update, rollback, recovery, factory reset, ownership transfer, and retirement. Some products add calibration, emergency operation, offline modes, safety overrides, diagnostic modes, or vendor-support access.

Each state can change:

Which identities are trusted.
Which interfaces are reachable.
Which code is allowed to run.
Which secrets are present.
Which data is retained.
Which actions are permitted.
Which events are logged.
Which recovery paths are available.

The current NIST IR 8259 Revision 1, finalized in April 2026, tells IoT product manufacturers to define expected customers and use cases, identify cybersecurity requirements, and plan how the product will support customer risk management. The companion NIST IR 8259A baseline includes device identification, configuration, data protection, logical access to interfaces, secure software update, and cybersecurity-state awareness.

Those capabilities do not exist only during normal operation.

They must remain meaningful while the product changes state.

Steady-State Testing Can Miss Transition Risk

Static firmware analysis can identify exposed secrets, unsafe configurations, vulnerable components, dangerous functions, and other defects inside an image.

Dynamic testing can examine running services, authentication, authorization, input handling, communications, and runtime behavior.

Hardware and interface testing can examine local access paths that a remote network assessment will never see.

Application and API testing can evaluate the services that control the device, store its data, and connect it to other systems.

The OWASP IoT Security Testing Guide reflects this broader reality by organizing testing around the device model, firmware, interfaces, communications, and runtime behavior rather than treating an IoT product as a single web endpoint.

The transition problem appears between those views.

Consider the questions created by an update:

Who is allowed to initiate it?
How does the device authenticate the update source and verify the image?
Can an authorized image be replayed after it should have expired?
What happens if power, storage, or connectivity fails halfway through installation?
Does rollback return the device to an older but vulnerable state?
Are security settings, keys, and logs preserved correctly?
Does the device report that it is running a degraded or unexpected version?

Now consider a factory reset:

Which user data is removed?
Which device identity and cryptographic material remain?
Are cloud registrations, mobile-app bindings, or vendor accounts disconnected?
Does the reset restore an unsafe default configuration?
Can a previous owner or administrator still reach the product?
Is the reset event visible to the next operator?

A review that tests only the stable image before and after the transition may miss the condition created during the transition itself.

Build a State-Transition Test Model

Start with a state diagram, not a tool list.

For each important transition, create a compact test record with six fields.

1. Entry condition: What starts the transition?

Identify the command, signal, physical action, scheduled event, fault, account action, or environmental condition that moves the device out of its current state.

Examples include an update request, boot failure, service-button sequence, cloud command, expired certificate, loss of connectivity, storage exhaustion, ownership transfer, or operator decision.

The entry condition should be testable. If the team cannot reproduce the condition safely, it cannot demonstrate how the product behaves when the condition occurs.

2. Authority: Who or what may cause it?

Name every actor that can initiate, approve, block, or complete the transition.

That may include the device owner, local administrator, vendor support team, cloud service, companion application, update-signing system, physical technician, automation service, or another device.

Then test the boundary between those roles.

An identity authorized to read device status should not automatically gain authority to install firmware. A field technician permitted to run diagnostics should not silently become a permanent administrator. A cloud service that can request an update should not be able to bypass the device’s independent verification of the image.

3. Protected state: What changes or persists?

List the assets and security properties that the transition can modify:

Firmware and boot components.
Configuration and policy.
Credentials, keys, certificates, and trust anchors.
User, customer, operational, or diagnostic data.
Device identity and ownership records.
Local and network interfaces.
Logging and monitoring state.
Safety limits and operating parameters.

Testing should confirm both what changes and what must not change.

4. Failure path: What happens when the transition does not finish normally?

Interrupt the process in a controlled environment.

Remove a dependency. Deny a required authorization. Present an invalid or older image. Exhaust an expected resource. Break connectivity at a defined step. Restart the device while state is being written.

The purpose is not to create theatrical destruction.

It is to learn whether failure moves the product into a secure, observable, and recoverable condition.

5. Evidence: What proves the resulting state?

Define the evidence an operator, customer, assessor, or incident responder can use to determine what happened.

That may include version and integrity measurements, event logs, update records, administrative actions, device-state reports, cloud audit records, tamper indicators, recovery results, or retained forensic artifacts.

If the device cannot explain its own security state, the organization may have to guess whether the transition succeeded.

6. Consequence: What can the new state affect?

Connect the technical result to the product’s real use.

Could the device disclose data, stop a business process, permit unauthorized control, produce incorrect measurements, lose availability, weaken a safety function, or become impossible to recover remotely?

The same technical defect can have very different significance in a consumer accessory, payment device, building controller, medical product, industrial sensor, or safety-related system.

Protect, Detect, and Recover

Device assurance is incomplete if it tests only whether unauthorized change can be prevented.

NIST SP 800-193 organizes platform-firmware resilience around three goals: protect the platform from unauthorized change, detect unauthorized change when it occurs, and recover rapidly and securely.

That sequence is a useful testing standard.

Protect

Verify that only authorized entities can initiate the transition and that the device independently validates the software, configuration, or command it is about to trust.

Test version policy, signing, authorization separation, local access controls, service interfaces, and the protection of keys and trust anchors.

Detect

Verify that the product can recognize and report an incomplete, unauthorized, degraded, or unexpected state.

An update mechanism that rejects a bad image but leaves no useful record may protect the device while weakening incident response. A device that boots a fallback image without reporting the version change may remain operational while concealing a material security event.

Recover

Verify that recovery returns the product to an intended trust state, not merely to an operable state.

The device may power on and still be running an obsolete image, unsafe configuration, untrusted key set, or diagnostic mode. Recovery evidence should show what was restored, which trust decision authorized it, and what follow-up action remains.

Physical Consequence Changes the Test Plan

Connected products can affect more than data.

The final NIST SP 800-82 Revision 3 defines operational technology broadly as programmable systems and devices that interact with the physical environment and emphasizes that security measures must account for performance, reliability, and safety requirements.

That changes how testing should be performed.

An aggressive production scan, unplanned reboot, malformed command, or interrupted update may be acceptable in a disposable lab unit and unacceptable in a live operational process. Some questions should be answered through offline firmware analysis, emulation, configuration review, representative hardware, isolated test networks, or a controlled lab before anyone considers validation in the field.

The test plan should distinguish:

What can be examined without operating the device.
What can be exercised safely on representative hardware.
What requires an isolated system or simulated environment.
What must be validated in the deployed environment under a carefully approved procedure.
What should not be tested actively because the safety or availability consequence is unacceptable.

Restraint is part of good testing.

The objective is not to prove that the assessor can break the device.

It is to produce useful evidence without creating the harm the assessment is supposed to prevent.

Scale Assurance by Consequence and Change

Not every connected product needs the same depth of testing.

A low-consequence, easily replaced device with no sensitive data and minimal authority does not need the same assurance program as a long-lived controller that can alter a physical process.

Set the testing tier using factors such as:

Safety and operational consequence.
Access to sensitive data or privileged actions.
Exposure to untrusted networks, users, or physical access.
Authority of local, wireless, cloud, and service interfaces.
Complexity of update, rollback, and recovery mechanisms.
Dependence on companion applications, APIs, and vendor cloud services.
Expected service life and ability to replace the product.
Availability of logs, integrity evidence, and emergency recovery.

Then define retest triggers.

A new firmware branch, bootloader, hardware revision, wireless stack, update service, cloud backend, cryptographic design, manufacturing process, or field-service workflow can change the transition model even when the product name remains the same.

The current NIST IR 8259 Revision 1 reinforces this lifecycle view by asking manufacturers to consider customer needs, product requirements, risk mitigations, and the support customers require to use the product securely.

Security testing should follow the product as those conditions change.

Measure Transition Assurance, Not Just Defect Counts

A vulnerability count is useful for remediation tracking.

It does not show whether the product preserves trust across its lifecycle.

More useful measures include:

Percentage of high-consequence state transitions represented in the test model.
Percentage of update and recovery paths that independently authenticate software and enforce version policy.
Percentage of reset, transfer, and retirement paths that remove customer data and obsolete account bindings as designed.
Percentage of maintenance and diagnostic actions attributable to a named identity.
Percentage of interrupted transitions that produce an observable security-state record.
Time required to recover a representative device to a known, supported, and verified state.
Number of product changes that altered the threat model but did not trigger security retesting.
Percentage of critical transition tests that include the companion application, API, cloud service, and deployed operating assumptions.

One question is especially revealing:

After an update, reset, or recovery fails, can you prove which trust state the device is in?

If the answer depends on a visual guess, undocumented service sequence, or the memory of one engineer, the product may be recoverable without being governable.

What Security Leaders Should Do This Week

Choose one connected product with meaningful business, safety, privacy, or operational consequence.

Draw its states. Include provisioning, normal operation, update, degraded operation, maintenance, recovery, reset, transfer, and retirement where applicable.
Name every transition authority. Identify who or what can initiate, approve, complete, or block each state change.
Map what changes and persists. Include software, configuration, identities, keys, data, interfaces, logging, and cloud bindings.
Choose one failure path. Safely interrupt an update, recovery, reset, or maintenance workflow on representative equipment.
Verify protect, detect, and recover. Confirm that unauthorized change is prevented, abnormal state is visible, and recovery restores a supported trust state.
Connect the result to consequence. Decide what the observed behavior could mean for safety, operations, customers, data, and incident response.
Set the retest triggers. Require reassessment when a material component, interface, update path, backend dependency, or field workflow changes.

A secure firmware image matters.

A hardened interface matters.

A tested API matters.

The product still has to move safely between the states that join those components together.

Test the transition.

That is where the device changes what it trusts.

Put MicroSolved’s Device and Lab Testing Experience to Work

MicroSolved, Inc. can help organizations evaluate industrial, IoT, embedded, and connected products through controlled, evidence-driven security testing.

MSI can assist with:

Product threat modeling and state-transition test design.
Firmware extraction, static analysis, emulation, and controlled runtime testing.
Review of local, network, wireless, service, application, API, and cloud interfaces.
Update, rollback, reset, maintenance, recovery, and retirement-path validation.
Embedded-device, firmware, AMI, SCADA, segmentation, and tamper-resistance assessment.
Test planning for high-availability, safety-sensitive, and critical-infrastructure environments.
Prioritized mitigation guidance that connects technical findings to business and operational consequence.

To discuss connected-device, firmware, industrial, or lab testing, contact MicroSolved at info@microsolved.com or +1.614.351.1237.

Relax. We’re on watch.

AI tools were used as a research assistant for this content, but human moderation and writing are also included.

The Leak Is Already Outside: Build an External Exposure Response Loop

Posted on October 20, 2026 by Brent Huston

The DLP dashboard is green.

Repository push protection is enabled. The approved file-sharing platform blocks public links. Managed laptops prevent copying sensitive files to removable media. The security team can point to policies, controls, alerts, and training.

Then someone finds a current API key in a public repository.

Or a configuration file in a support forum. A source-code fragment in a paste. An internal hostname in a public issue. A customer data sample in a forgotten cloud share. A credential in a contractor’s fork.

The organization did not see the information leave.

That does not make the exposure less real.

This is the gap between data-loss prevention and external-exposure response. Prevention controls watch selected systems, users, repositories, interfaces, and transfer paths. They are necessary. They are not proof that sensitive information never crossed a path the organization could not see.

The practical lesson is simple:

A data-protection program is incomplete until it can find, neutralize, and learn from sensitive information that is already outside the managed boundary.

Prevention Sees the Paths It Controls

Organizations should prevent sensitive data from leaving in the first place.

That includes classifying information, limiting access, using secrets managers, scanning source code, blocking known secret patterns, controlling file sharing, monitoring managed endpoints, and reducing the lifetime and authority of credentials.

The joint CISA and FBI guidance on Product Security Bad Practices identifies hardcoded credentials and secrets in source code as a dangerous practice for products used in critical infrastructure and recommends secrets managers and scanning within the development process.

GitHub provides another useful example. Its secret-security guidance distinguishes push protection, which attempts to stop supported secrets before they enter a repository, from secret scanning and public monitoring, which identify exposures that already exist. GitHub describes public monitoring as visibility into credentials exposed beyond repositories owned by the enterprise.

That distinction matters.

Preventive and detective controls are not interchangeable. One attempts to stop the event. The other assumes prevention can fail and looks for evidence afterward.

Even strong platform controls have scope. GitHub’s own secret-scanning documentation describes supported patterns, pair-matching conditions, legacy-token limitations, large-push conditions, and other cases in which push protection may not detect or block a secret.

That is not an argument against push protection.

It is an argument against treating any point control as proof of absence.

Public repositories are only one possible destination. Sensitive material can also appear in support portals, issue trackers, package artifacts, code forks, shared folders, archived pages, discussion sites, and third-party systems. Some of those channels belong to the organization. Others do not. Some produce useful logs. Others may provide only a timestamp, a URL, and a copy of what was exposed.

The control model must account for both conditions:

Prevent what can be prevented inside managed workflows.
Monitor and respond where prevention cannot provide complete visibility.

Treat External Exposure as Incident Evidence

Finding sensitive material outside the organization is not merely a content-cleanup task.

It may be evidence of an incident.

An exposed credential may still authorize access. A configuration may reveal trust relationships, administrative interfaces, naming conventions, or control gaps. Source code may disclose intellectual property, security assumptions, embedded secrets, or exploitable implementation details. A customer record may trigger privacy, contractual, legal, or regulatory obligations. A seemingly harmless internal identifier may help an attacker improve targeting.

The correct response depends on what the artifact can do, what it reveals, how current it is, and who may have obtained it.

This is why deletion alone is not containment.

Removing a repository, post, attachment, or cached page can reduce continuing exposure. It does not invalidate a credential, erase copies, reverse indexing, identify prior access, or prove that the information was never used.

For secrets, the priority is authority.

The OWASP Secrets Management Cheat Sheet recommends that secrets be revocable, rotated, limited in lifetime and privilege, and supported by lifecycle records that help responders understand who had access and when the secret was used or changed. Stopping the application or deleting the exposed file does not necessarily revoke the credential behind it.

For other data classes, the priority may be different. The organization may need to preserve evidence, restrict further access, notify an owner, assess contractual scope, request removal, investigate misuse, or determine whether the material exists in additional locations.

The external artifact is the beginning of the response question, not the end.

Build the External Exposure Response Loop

A practical external-exposure capability has five stages: discover, classify, neutralize, trace, and learn.

1. Discover: What is visible outside the boundary?

Define the sensitive artifacts the organization cares enough to recognize.

The list may include:

Credentials, tokens, private keys, and connection strings.
Source code and proprietary algorithms.
Device, cloud, application, and network configurations.
Internal domains, hostnames, project names, and administrative paths.
Customer, employee, regulated, or contractually protected data.
Documents carrying distinctive identifiers, watermarks, or structured patterns.

Then define the monitoring scope, frequency, owners, escalation path, and evidence-handling requirements for each class.

No discovery method sees the entire internet. A useful program therefore states its coverage and blind spots explicitly. It distinguishes continuous monitoring from periodic searches, platform-native scanning from broader exposure monitoring, and confirmed findings from possible matches that still require analyst validation.

The goal is not to claim universal visibility.

The goal is to reduce the period during which a consequential exposure remains unknown.

2. Classify: What can the artifact enable?

Do not prioritize solely by how embarrassing the artifact looks.

Classify it by authority, sensitivity, current validity, exploitability, reach, and affected business process.

Ask:

Is this an active secret, an expired secret, or a string that only resembles one?
What systems, data, funds, or actions could it authorize?
Is the artifact complete enough to use, or does it become dangerous when combined with other information?
Is the exposed copy current, historical, partial, or modified?
Does it contain regulated data, customer information, trade secrets, or security architecture details?
Is it publicly accessible, indexed, cached, mirrored, or limited to a narrower audience?
Who owns the asset and who has authority to contain it?

The fastest path to a good decision is a prepared owner map. Security should not discover during the incident that nobody knows who can rotate the key, suspend the integration, contact the platform, interpret the contract, or decide whether operations can tolerate emergency change.

3. Neutralize: Remove authority before chasing every copy

If an exposed artifact grants access, invalidate that authority first.

Revoke the token. Rotate the key. Terminate sessions. Disable the account. Restrict the affected interface. Replace the certificate. Narrow the permission. Add temporary monitoring or access controls while the permanent change is implemented.

Then address continuing availability of the artifact through the appropriate channel: delete an owned copy, request removal, use an established takedown process, restrict a share, or work with the platform or third party that hosts it.

Containment order matters.

If responders spend hours removing a public page while the exposed credential remains valid, they are reducing visibility without reducing authority. A downloaded copy can still work.

The neutralization plan must also account for dependencies. Rotating one secret may break applications, vendors, automated jobs, recovery processes, or downstream services. That is a reason to engineer revocation and replacement paths before an incident, not a reason to keep exposed authority alive.

4. Trace: How did it get there, and what happened next?

Once the immediate risk is controlled, reconstruct the path.

Determine:

Where the artifact originated.
Which person, system, process, or third party handled it.
When it became exposed and when the organization discovered it.
Whether logs show access, authentication, downloading, reuse, or related activity.
Whether the same material exists in forks, mirrors, archives, tickets, backups, chat systems, or build artifacts.
Whether similar artifacts were created by the same workflow.
Whether an attacker could combine the finding with other public information.

NIST SP 800-61 Rev. 3 frames incident response as part of cybersecurity risk management rather than a stand-alone activity and connects preparation, detection, response, and recovery. External-exposure work should follow the same logic. The team needs enough evidence to reduce immediate impact and improve the system that allowed the exposure.

Tracing must remain proportionate. Not every public identifier justifies a full forensic investigation. Not every old credential remains usable. The classification stage should drive the depth of response.

5. Learn: Which control or assumption failed?

The last stage converts a one-time cleanup into program improvement.

An exposure may reveal:

A secret embedded in code because the approved retrieval method was too difficult.
A repository that did not inherit the organization’s security configuration.
A contractor or vendor using an unmanaged development workflow.
Sensitive troubleshooting data copied into a support channel.
A DLP policy that covered endpoints but not build logs or cloud collaboration.
A credential with excessive privilege or no practical rotation process.
A data classification rule that employees could not apply to real work.
An alert that reached a mailbox nobody owned.

Fix the common cause, not only the visible artifact.

The question is not simply, “Did we remove it?”

The better question is, “What changed so that the same process is less likely to expose the next artifact?”

Prioritize Authority, Exposure, and Business Consequence

External findings need a decision model.

A useful triage approach considers three dimensions.

Authority

What can the artifact authorize or enable?

An active administrative credential, signing key, production token, or remote-access configuration may require immediate containment. A disabled test credential may require documentation and process correction without the same urgency.

Exposure

Who could obtain it, and for how long?

Public, indexed, and mirrored content has a different exposure profile from a restricted ticket available to a small support team. However, restricted does not mean safe. Third-party access, retention, forwarding, and account compromise still matter.

Business consequence

What could happen if the information is used or disclosed?

Consider system control, customer harm, financial movement, service disruption, regulatory scope, intellectual property, safety, contractual commitments, and reputational impact.

These dimensions prevent two common mistakes.

The first is treating every match as a crisis.

The second is treating a small-looking artifact as harmless when it carries substantial authority.

Measure the Response, Not Just the Number of Hits

Raw alert volume is a weak success measure.

More useful measures include:

Time from external publication to discovery.
Time from discovery to owner acknowledgement.
Time to invalidate active authority.
Time to determine the affected systems and data.
Percentage of high-impact secrets with a tested emergency rotation path.
Percentage of material findings with preserved evidence and documented disposition.
Recurrence rate by workflow, business unit, vendor, repository, or artifact type.
Percentage of monitoring patterns with a named owner and review date.
Number of findings that produced a control, process, or architecture improvement.
Percentage of high-risk exposures for which misuse could be assessed from available logs.

One metric deserves special attention:

How long does it take to make a discovered artifact harmless?

Discovery creates the opportunity to respond.

Neutralization changes the risk.

Where ClawBack Fits

MicroSolved currently positions ClawBack™ as a data-leak detection capability supporting exposure monitoring, advisory retainers, and vCISO relationships, with evidence that can support response conversations.

That is the right place for external-exposure monitoring in the operating model.

Its job is not to replace DLP, repository controls, secrets management, identity governance, incident response, or legal and privacy review. It helps close the visibility gap between what internal controls observed and what may be visible outside the organization.

The value of a finding depends on the process around it:

What classes of information are in scope?
Which sources and channels are monitored?
How are possible matches validated?
Who owns each artifact class?
What evidence is preserved?
What requires immediate escalation?
How will credentials be revoked, files removed, and downstream impact assessed?
How will lessons feed back into prevention?

ClawBack should therefore be treated as part of an exposure-response capability, not as an isolated alert feed.

What Security Leaders Should Do This Week

Choose one artifact class with meaningful business consequence: production API keys, administrative credentials, network configurations, source code, customer records, or another clearly owned data set.

Then run this exercise:

Define what a recognizable exposure looks like. Identify patterns, identifiers, owners, and likely external channels.
Document current coverage. Record which preventive and detective controls can see the artifact, and which paths remain outside their scope.
Prepare the owner map. Name the people who can classify the finding, revoke authority, approve operational impact, preserve evidence, request removal, and assess notification obligations.
Test neutralization. Measure how long it takes to revoke or replace the artifact without creating uncontrolled business disruption.
Simulate one discovery. Walk the finding through discover, classify, neutralize, trace, and learn.
Verify the logs. Confirm that responders can determine whether the artifact was used and which systems were affected.
Close one recurring path. Improve the workflow most likely to produce the same exposure again.

Data-loss prevention is important.

Secret scanning is important.

Repository protection is important.

None of them can prove that sensitive information is absent from every external place the organization does not control.

Build the response loop for the moment the leak is already outside.

Put External Exposure Monitoring Into the Security Program

MicroSolved, Inc. can help organizations:

Define external-exposure monitoring requirements for credentials, source code, configurations, and other sensitive artifacts.
Integrate ClawBack findings into vCISO, advisory, and incident-response workflows.
Build artifact classification, ownership, escalation, and evidence-handling processes.
Test credential revocation, session termination, takedown, and downstream-impact procedures.
Review DLP, repository, secrets-management, vendor, and cloud-collaboration control gaps.
Turn recurring exposures into practical control and process improvements.

To discuss ClawBack or an external-exposure response review, contact MicroSolved at info@microsolved.com or +1.614.351.1237.

Relax. We’re on watch.

AI tools were used as a research assistant for this content, but human moderation and writing are also included.

Authentication Is Not the Finish Line: Secure the Token Lifecycle

Posted on September 21, 2026 by Brent Huston

A user signs in with a passkey. The authentication is phishing-resistant. The identity provider records a successful challenge. Every dashboard says the login worked as designed.

Hours later, an attacker reuses a stolen session token.

No password is entered. No push notification appears. No new authentication ceremony occurs. The application sees a valid artifact and accepts it.

Both facts can be true at the same time: the authentication was strong, and the session was compromised.

That is the identity problem security programs need to address next.

Passkeys, hardware security keys, conditional access, and stronger account recovery are essential. They protect the process of establishing identity. But modern applications rarely ask a person or workload to prove identity again for every action. They rely on tokens and assertions that carry the result of an earlier decision across applications, APIs, clouds, and sessions.

The security boundary therefore does not end at login. It moves with the token.

NIST and CISA made that point operational in the final September 2026 release of NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse. The report addresses the keys that create trust, the systems that validate it, the lifetime of tokens, session monitoring, revocation, workload identity, and the division of responsibility between cloud providers and their customers.

The practical lesson is straightforward:

Treat every token as a live authorization decision, not as a receipt proving that authentication once succeeded.

Continue reading →

Three Field Guides for the Security Problems Showing Up Right Now

Posted on September 14, 2026 by Brent Huston

Over the last several months, we have released three longer-form guides around problems we keep seeing in real environments:

The Antifragile SOC Book
The AI Agents Management Framework
The Security Leader’s Operating System

They cover different areas, but they share a common theme: how to operate effectively as complexity, automation, and pressure increase.

Books

Why We Created These Materials

These guides did not begin as content projects.

They came from working problems.

Over the years, we have accumulated a lot of models, processes, questions, and operating approaches that we use when helping organizations solve difficult security problems. Some came from client work, some from research, and plenty came from lessons learned the hard way.

Much of that knowledge lived in conversations, notes, presentations, and experience.

We decided it was time to write more of it down.

Not as theory, and not as another collection of cybersecurity predictions.

As practical field material people can use, challenge, adapt, and apply.

Continue reading →

Vendor Evidence Is Now a Cyber Materiality Risk

Posted on June 29, 2026 by Brent Huston

A cybersecurity incident does not care where your data lives.

It does not care that the affected application is vendor-managed. It does not care that the logs are in a SaaS console your team cannot access. It does not care that the data-flow diagram is maintained by procurement, that customer-impact details live with a managed service provider, or that the outage timeline depends on a third-party support ticket.

But your materiality decision may care very much.

Public companies must disclose material cybersecurity incidents on Form 8-K within four business days after determining that the incident is material. The SEC’s rule also requires disclosure of the material aspects of the incident’s nature, scope, timing, and impact or reasonably likely impact, and the materiality determination must be made without unreasonable delay after discovery.

That creates a practical problem many organizations have not fully internalized:

The disclosure clock may be yours, but the evidence may belong to someone else.

That is not just a legal nuance.

It is an operational design problem.

It is a governance problem.

Continue reading →

AI Agents Need Autonomy Budgets, Not Just Governance Policies

Posted on June 22, 2026 by Brent Huston

Most organizations are granting AI agents authority faster than they are defining the limits of that authority.

That is the problem.

We have already started treating AI agents as digital workers. That is the right mental model. An agent that can access data, call tools, trigger workflows, generate artifacts, influence decisions, or alter enterprise state is not just another application. It needs identity. It needs boundaries. It needs oversight. It needs evidence. It needs a human owner. It needs a kill switch. That has been the right foundation for agent governance.

But it is not enough.

There is another question that needs to be asked much earlier:

How much damage is this agent allowed to cause before a human must approve the next action?

Not theoretically.

Not in vague risk language.

In actual economic terms.

How much money can it spend?
How many systems can it change?
How many records can it touch?
How much customer impact can it create?
How much privacy exposure can it cause?
How much reputational risk can it accumulate?

If we cannot answer those questions, we have not governed autonomy.

Continue reading →

Account Recovery Is Becoming the New Identity Attack Surface

Posted on June 16, 2026 by Brent Huston

As passkeys and phishing-resistant authentication reduce password risk, attackers will move pressure to the recovery plane.

The industry is moving in the right direction.

Passkeys, FIDO2/WebAuthn, hardware security keys, conditional access, better MFA policies, and risk-based sign-in controls are all meaningful improvements. They reduce entire classes of credential theft. They make phishing harder. They remove reusable passwords from many authentication ceremonies. They shift more of the security burden from user judgment to protocol design.

That is good.

But it is not the finish line.

In my recent passkeys article, I called out a point that deserves its own treatment: passkeys do not solve weak account recovery, help desk social engineering, stolen session tokens, OAuth consent abuse, unmanaged vendor access, or excessive privilege. They are a major step forward, but they do not remove the rest of the identity attack surface.

That matters because attackers adapt.

Continue reading →

Passkeys, Not Passcodes: A Practical Enterprise Guide to Moving Beyond Passwords

Posted on June 10, 2026 by Brent Huston

There is a small terminology problem in the identity world right now, and it matters more than it looks.

A passcode or PIN is usually a local unlock secret. It unlocks a phone, a laptop, Windows Hello, an authenticator app, or a hardware security key. A passkey is different. A passkey is the standards-based replacement for passwords, built on FIDO2/WebAuthn. The user unlocks the passkey locally with a fingerprint, face scan, device PIN, pattern, or security key, but the website or application receives cryptographic proof — not a reusable password. FIDO defines passkeys as FIDO authentication credentials based on FIDO standards, tied to an account, and used with the same process the user already uses to unlock a device.

That distinction is not pedantry. It is the difference between a local unlock method and a replacement for one of the most abused controls in the history of computing.

Passwords have had a long run. They also have had a long list of failures: reuse, phishing, spraying, stuffing, database theft, weak reset workflows, help desk abuse, and user fatigue. We have spent decades trying to compensate for those failures with complexity rules, expiration schedules, password managers, SMS codes, mobile push prompts, training campaigns, and detective controls.

Some of those helped. Some just moved the pain around.

Passkeys change the model.

Continue reading →