DEVICE INTELLIGENCE
Recognize returning devices and review the evidence behind them
A browser script assesses the visitor's browser and returns a site-scoped device handle with a risk read. Your backend reads the record and applies your own policy.
WHAT YOU GET
Device evidence you can review and carry into policy
Each assessment gives your team a handle, risk fields, and the context behind them.
- Earlier visit
- Later visit, same browser
Handle A
Risk read: level, confidence, reasons
- After clearing storage
New handle B
Continuity broke. A new or missing handle is not a low-risk result.
Site-scoped device handle
Recognize whether a browser or device context has been seen before under your site. Carry the handle into your own session or account workflow where your policy allows.
Risk read with reasons
Each assessment returns a score, a named risk level, a confidence value, and named reasons. Review the fields together instead of treating the score as a verdict.
History and comparison
Find a device, review its visits, and compare profiles in the operator console. Where enabled for your tenant, follow related devices. Relationships are leads, not proof. History follows your workspace retention and access settings.
Consent-aware collection
Optional collection follows the consent and admission settings you configure. You remain responsible for the legal basis and the notices your visitors see.
HOW IT WORKS
From browser evidence to your backend decision
The browser collects evidence. Your server performs the authenticated read. Your application owns the policy and every fallback.
Your page
Collector script
Assesses the browser on your provisioned origin.
Noxtica
Handle and risk read
Evidence from the page
A site-scoped device handle, or an unavailable state.
Your server
Authenticated lookup
Just the device identifier
Reads the record with a server-held credential.
Your policy
Your decision
Level, confidence, reasons
You choose the action. Noxtica does not decide.
Collect in the browser
A script on your provisioned origin assesses the browser. It emits a device identifier or an error state. It never receives a server credential. The runtime is designed to raise the cost of tampering and replay.
Read on your server
Send just the device identifier to your backend. Your backend performs the authenticated lookup with a server-held credential. Missing, invalid, rate-limited, and unavailable responses stay distinct.
Apply your policy
Combine the record with your own account, operation, and abuse context. Evaluate proposed actions in observation mode before enforcement. Noxtica does not make the final decision.
WHERE IT FITS
Questions device evidence helps answer
Use it where your team has a defined decision and a fallback. Do not collect an identifier just because you can.
Is this a new or returning device?
Inform login, account recovery, and step-up decisions. A familiar handle still goes through normal authentication. Familiarity is not approval.
Does this signup look repeated?
Compare device context across sessions to spot repeated signup or promotion abuse. Shared devices and shared networks can limit what you can conclude.
Why did this session get friction?
Give support and fraud teams a repeatable reference when they review a session or a transaction alongside account context.
HOW TEAMS CONNECT
Browser script and authenticated server lookup
These are the current public integration surfaces. Both need evaluation access.
- Browser script: add the collector script to pages on a provisioned origin, with your public site key. It reports a device identifier or an unavailable state to your page code.
- Authenticated server lookup: 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 developers page shows the maintained path and the current support matrix. Contact the team to request evaluation access.
LIMITS TO PLAN FOR
What a device handle cannot tell you
Plan for these boundaries before you rely on the output.
- Not a person. A device handle is not a verified person or account owner. It can represent a browser profile rather than a single physical device.
- Continuity varies. Clearing storage, private browsing, blocked scripts, privacy tools, consent choices, and changed devices can break continuity or reduce evidence. A missing result is not a low-risk result.
- 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. 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.
Scores, reasons and verdicts are probabilistic estimates, not statements of fact. Your team makes every decision.Read the disclaimer
FAQ
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.
Related products
DEVICE INTELLIGENCE
Prove the handoff before you change policy
Request a technical evaluation. We provision your origin and public site key. You then test collection, lookup, and fallback states in observation mode before any enforcement.