בעמוד זה

Know Your Device (KYD)

Definition. Know Your Device is Noxtica’s browser-based device-intelligence concept. It turns a browser assessment into a site-scoped fingerprint identifier and risk context that can be used across permitted sessions and backend workflows.

The problem it solves is continuity without pretending to know a person. Account and fraud teams often need to ask whether a browser/device context has been seen before, whether its characteristics are internally consistent, and what risk evidence accompanied the assessment. KYD provides those inputs without making the final decision.

A device identifier is not a verified person, account owner, or guaranteed physical device. It is a handle for the assessed context under the current site, browser, storage, and collection conditions.

When it applies

KYD can inform:

new-device and returning-device review;
signup and promotion-abuse controls;
login, account recovery, and step-up decisions;
transaction review alongside account and payment context; and
support investigations into why a session received friction.

Use KYD where your team has a defined decision and fallback. Do not collect an identifier merely because it is available.

How customers use it

Add the browser collector with a provisioned Site Key.
Call checkOnce() or use automatic collection to receive the current browser result.
Store fingerprintId with the relevant session or account when your retention and access design permits it.
Read the current risk context in the operator console or retrieve device data from the Server API with a scoped server key.
Combine device history and risk fields with your own account, route, and transaction context.
Apply the action in your backend or through separately provisioned policy controls.

See Getting started for collection and Backend integration for the supported lookup workflow.

How Noxtica does it

Browser Intelligence gathers multiple categories of browser and edge context. KYD presents the resulting customer-facing artifacts:

Fingerprint identifier — a site-scoped handle returned as fingerprintId.
Device history fields — supported first-seen, last-submitted, and last-seen timestamps available through device lookup.
Risk score and level — a 0–100 score and named tier for policy segmentation.
Confidence — context for how strongly to rely on the assessment.
Flags or reasons — contributing conditions an operator can investigate.
History and comparison — in the operator console, find a device, review its visits, and compare profiles. Where enabled for your tenant, follow related devices; relationships are leads, not proof. History follows your workspace retention and access settings. See Fingerprints, analytics and live monitoring.

The protected browser runtime is designed to raise the cost of result manipulation and replay. It does not make a browser impossible to inspect, guarantee continuity, or establish a hardware or legal identity.

Outputs and decisions

Output	Customer use
`fingerprintId`	Associate permitted observations with a session or account workflow
First/last-seen context	Distinguish newly observed from previously observed context
`score` and `riskLevel`	Select a route-specific review or step-up band
`confidence`	Decide whether the available evidence supports a strong action
`flags`	Explain and investigate what contributed to risk

For example, a newly observed identifier with elevated risk and limited confidence may warrant reversible step-up rather than a permanent denial. A familiar identifier still passes normal authentication and authorization; familiarity is not approval.

Supported limitations

Clearing storage, private browsing, browser or device changes, privacy tools, blocked scripts, and collection settings can affect continuity or available evidence.
A fingerprint can represent a browser profile rather than a single immutable physical device.
Cross-site tracking is not the customer contract; use the identifier only within the provisioned tenant and site context.
Cached assessments can be older than the current visit. Use the configured refresh interval and timestamps when freshness matters.
Native iOS or Android attestation is separate from browser KYD and requires its own supported integration and tenant eligibility.
Risk output complements but does not replace identity verification, authentication, authorization, or transaction controls.

Where it fits

KYD is the device part of the Intelligence pillar. It receives evidence from Browser Intelligence, complements eligible Know Your Agent context, and supplies inputs to Browser Security or customer-owned backend policy.

Who it fits

Device evidence suits teams that own a defined decision and a fallback. When it applies lists the decisions it can inform, and Outputs and decisions explains why a familiar handle is not approval.

Repeated signups. Shared devices and shared networks can limit what you can conclude when you compare device context across sessions.
Support and fraud review. Use the handle as a repeatable reference when you review a session or a transaction alongside account context.

How teams connect

These are the current public integration surfaces. Both need Evaluation access.

Browser script. Follow Getting started and Browser runtime. The script runs on pages of a provisioned origin and reports a device identifier or an unavailable state to your page code.
Authenticated server lookup. Follow Backend integration. Your backend sends the device identifier and reads the tenant-scoped record with a server-held credential. Keep that credential out of browser code.
Technical evaluation. The developer overview shows the maintained path and the current support matrix. Contact the team to request Evaluation access.

Integration flow traces the whole path from browser to policy.

Limits

Plan for these boundaries before you rely on the output.

Not a person, and continuity varies. The opening definition and Supported limitations cover what a handle represents and what breaks continuity. A missing result is not a low-risk result; treat it as unknown. Consent choices can also reduce evidence.
Estimates, not facts. Scores, risk levels, and reasons are probabilistic. They are not statements of fact or certifications. Your team makes every decision. Read the disclaimer.
Your responsibilities. Optional collection follows the consent and admission settings you configure. Device handles and browser characteristics can be personal data, depending on law and use. You own the notices, consent, and legal basis for collecting them.

Common questions

Does a device handle identify a person?

No. It identifies an assessed browser or device context under your site. Use identity verification when you need evidence about a person.

Does Device Intelligence block traffic?

No. It returns evidence. Your backend, or policy controls you provision separately, decides whether to allow, step up, review, or deny.

What happens if collection fails or is blocked?

Your page receives an error or unavailable state, and no fresh evidence arrives. Treat that state as unknown, not low risk, and define a fallback.

Read deeper

Getting started — collect the current browser result.
Device API reference — retrieve device risk with a scoped server key.
Browser runtime — cache, lifecycle events, errors, and collection modes.
Features: device and browser intelligence — interpret the identifier and its risk context.
Why calibration, not verdicts — choose policy without treating risk as identity.
Browser Intelligence — the evidence categories that feed KYD.