Start with the plain meaning of each word, then see why the combination matters.

A device is the computer, phone, or tablet a person uses to reach company apps. Trust, in security, means a decision to believe something is safe enough for a given purpose. Device trust is therefore the practice of checking a device, deciding whether it deserves trust, and using that decision when deciding what the person using it may do.

In Okta, this usually works in layers. Okta can find out whether a device is known to the company at all. It can find out whether the device is managed by the company’s own device management system. And it can check basic health facts, such as whether the operating system is recent enough or the disk is encrypted. Policies then use these facts to allow, challenge, or deny access.

This guide stays at a foundation level. It explains the ideas, the vocabulary, and the planning questions. It does not walk through every console screen, since names and steps change between releases and are best taken from Okta’s current documentation.

Three questions this guide answers

Everyday phrases and what they really mean

Identity teams use short phrases that confuse newcomers. When someone says “the device is registered”, they mean Okta knows this device and has linked it to a person. When they say “the device is managed”, they mean the company’s device management system also vouches for it. When they say “posture”, they mean the health of the device, such as whether it is encrypted and up to date. Knowing these three words makes most documentation much easier to read.

Strong sign-in proof is not enough if the machine itself cannot be trusted.

For many years, security focused on the person. If someone knew the right password and passed the second check, they were let in. But a person is always sitting at a device, and the device can be the weak point. A laptop infected with malicious software can steal sessions after a perfectly valid sign-in. An old phone missing security updates can leak data. A shared home computer can leave copies of files behind.

Working from anywhere has made this worse. Staff now use laptops at home, phones on trains, and personal tablets on weekends. Companies cannot see or control every one of those machines. Yet the same apps and data are reachable from all of them. The company needs a way to tell the safe machines from the doubtful ones, and to treat them differently.

What goes wrong without device awareness

Why this matters even for small teams

Some teams believe device trust is only for large enterprises. In truth, the questions begin the day a company has staff using personal laptops or phones to read company email. A small firm with ten people and a shared cloud drive faces the same basic risk, only on a smaller scale. Writing down which devices are allowed, and what each may reach, costs an afternoon. Untangling a rushed setup after it has spread to hundreds of people costs months.

A short vocabulary list makes everything that follows easier to read.

Device security has its own words. Most of them describe what is known about a device, or who vouches for it. The table below puts each term next to a simple picture to remember it by.

Registered is not the same as managed

This difference trips up many newcomers. A registered device is one that Okta has seen and linked to a person, for example because the person enrolled Okta’s app on it. A managed device goes a step further. The company’s own device management system also confirms it is under company control. Registered answers “does Okta know this device?” and managed answers “does the company control it?”.

Common misunderstandings

Trust is not a switch. It comes in steps, and each step can unlock different things.

It helps to picture three broad levels. At the lowest level, the device is unknown, and Okta has no history with it. At the middle level, the device is registered, so Okta knows it and has tied it to a person. At the highest level, the device is managed, meaning the company’s device management system also vouches for it. On top of any level, health checks can add or remove confidence.

Why steps are better than a switch

If trust were only yes or no, every device would be either fully welcome or fully blocked. Real life is more varied. A personal phone may deserve access to email but not to the finance system. A managed laptop with an outdated system may deserve a warning first and a block later. Steps let you design a gentle path for each situation.

Modern security asks about the person and the device together. This pairing is part of a wider idea called zero trust.

Older security models trusted anything inside the company network. If you were in the building, you were assumed safe. Zero trust is a newer idea that says no one and nothing is trusted just because of where it sits. Every request is checked, using several signals. Device trust is one of the most useful of those signals.

The signals that can be combined

No single signal is perfect. A password can be stolen. A location can be disguised. A device can be infected. But when several signals agree, confidence rises. When one signal looks odd, such as a valid password from an unknown device in a new country, the system can ask for more proof or refuse.

A few more words you will hear in meetings

Colleagues may say “endpoint” when they mean any device that connects to the network, such as a laptop or phone. They may say “compliance state” when they mean whether a device currently meets the company’s rules. They may say “conditional access” when they mean access that depends on conditions such as the device, the place, or the risk. And they may say “attestation” when a device offers proof about its own state, backed by its hardware.

None of these words is hard. Each names a piece of the picture you have already seen. When a new term appears, ask which of the four buckets it belongs to: knowledge, control, health, or decision. Placing the word in a bucket usually reveals what it means and who is responsible for it.

Here is the full picture of how a device, Okta, and the company’s management tools work together.

The design has a few clear parts. On the device sits a small agent, often Okta’s own app, that can talk to Okta. Elsewhere sits the company’s device management system, which knows which devices it controls and how healthy they are. Okta stands in the middle. It gathers facts from the device and from the management system, and policies use those facts when someone signs in.

flowchart LR
  subgraph DeviceSide["Device Side"]
    P["Person"]
    D["Laptop or phone"]
    AG["Okta app on the device"]
  end
  subgraph CompanyTools["Company Tools"]
    MDM["Device management system"]
  end
  subgraph OktaZone["Okta"]
    INV["Device inventory"]
    AP["Policies and device assurance"]
    LOG["System Log"]
  end
  APP["Protected application"]
  P --> D
  D --> AG
  AG -->|"Register and report device facts"| INV
  MDM -->|"Confirm management and health"| INV
  INV --> AP
  P -->|"Sign in request"| AP
  AP -->|"Allow, challenge, or deny"| APP
  AP --> LOG

The components, one by one

Why the middle matters

Everything passes through Okta’s policies. That means device facts are used consistently, no matter which app the person wants. A single policy change can affect every sign-in that matches it, which makes device rules powerful, and a reason to change them with care.

Before Okta can trust a device, it must first meet it. That first meeting is called registration.

Registration is the step in which a device and a person are linked inside Okta. In many setups, this happens when the person installs and sets up Okta’s app on the device. During setup, the app creates a secret that stays on the device and shares a matching public part with Okta. From then on, Okta can recognize this particular device when it returns.

sequenceDiagram
  autonumber
  participant U as User
  participant A as Okta app on device
  participant O as Okta
  U->>A: Install and open the app
  A->>O: Ask to register this device
  O->>U: Ask for sign-in proof
  U->>O: Provide password and second proof
  O-->>A: Approve registration
  A->>A: Create a secret key that stays on the device
  A->>O: Share the matching public part and device facts
  O-->>U: Device is now registered

Why Okta asks for proof before registering

If anyone could register any device on any account, an attacker with a stolen password could register their own machine and gain a trusted place. For that reason, registration asks the person to prove who they are first. After registration, that device can sometimes give a smoother sign-in, which is the reward for passing the first careful check.

What can go wrong at registration

Registration tells Okta a device exists. Management status tells Okta that the company controls it.

Many companies already use a device management system, often called MDM, short for mobile device management, or a similar endpoint management tool. Well-known products in this space include Microsoft Intune, Jamf, and VMware Workspace ONE, among others. These tools install settings, push updates, enforce encryption, and can erase a lost device remotely.

Okta can be connected to such a system so that it can learn which devices the company manages. Once connected, a device that is registered in Okta and also confirmed by the management system can be treated as managed. Policies can then give managed devices a stronger level of trust than registered-only ones.

How the two sides meet

Why the match matters

Without the link, Okta can only say that a device exists. With the link, Okta can also say that the company controls it and can erase it if lost. This second statement is much stronger. It is what lets a company confidently say “sensitive apps open only from managed devices”.

Being known and managed is not enough. A device must also be in good shape.

Device assurance is a way of describing the minimum health a device must have. You write a set of rules, such as “the operating system must be recent”, “the disk must be encrypted”, and “the screen must lock itself”. Okta then checks each device against those rules. A device that passes is considered healthy for that purpose, and a device that fails is not.

Common health checks

Different rules for different platforms

Computers, phones, and tablets have different features and different update habits. A good design writes separate assurance rules for each kind of device, with numbers that fit reality. A rule that demands the very latest version of a system on the day it is released would lock out half the company. A rule that accepts versions from five years ago protects very little. The best rules sit a sensible step behind the newest.

Warn first, block later

When you first introduce a health rule, many devices will fail it, simply because nobody checked before. Blocking them all at once would cause an outage. A kinder path is to warn first, giving people time to update, and to block only after the warning period ends. Watching the numbers during the warning period shows how many people need help.

Knowing about a device is only useful if rules act on it. Here is how policies use device context.

Okta’s policies are made of rules, and each rule has conditions and actions. A device-aware rule adds a condition about the device, such as “the device is managed” or “the device meets assurance”. The action then says what happens when that condition is true or false, such as allowing access, asking for an extra proof, or denying access.

A simple pattern of rules

Where device conditions live

In Okta Identity Engine, device conditions are usually part of authentication policies, which belong to applications. This means each app can ask for its own level of device trust. The payroll app can demand a managed, healthy device, while the company news site asks for nothing special. Details can differ between versions, so confirm where your edition places these conditions.

Rules should be simple and ordered

Because the first matching rule wins, the order matters. Put the most specific rules first, such as “sensitive app on an unmanaged device”, and the general ones last. A broad rule at the top can hide a strict rule below it completely. Keep rules short, give them clear names, and test them with real examples.

Thinking in layers of evidence

A helpful habit is to picture each sign-in as a small pile of evidence. The person’s proof is one item. The device’s registration is another. The management confirmation is a third, and the health check is a fourth. The more items in the pile, and the stronger each item, the more confident the system can be. When the pile is thin, the system asks for more or says no.

This picture also explains why no single feature should carry all the weight. If one item in the pile is forged or goes stale, the other items still stand. Designing with layers means that a failure in one place makes the system a little weaker, not completely open.

Follow one sign-in through the decision, and see where the device takes part.

When a person opens an application, Okta gathers facts about the sign-in. It knows the person and their proofs. It looks up the device, checking registration, management, and health. It then walks through the policy rules in order, stops at the first rule that matches, and applies its action. The result is access, a challenge, or a refusal.

flowchart TD
  S["Person opens an application"] --> K{"Is the device known to Okta?"}
  K -->|"No"| U["Treat as unknown device"]
  K -->|"Yes"| M{"Is the device managed?"}
  M -->|"No"| R["Treat as registered only"]
  M -->|"Yes"| H{"Does it meet health rules?"}
  H -->|"Yes"| T["Treat as managed and healthy"]
  H -->|"No"| W["Treat as managed but unhealthy"]
  U --> P["Policy rules decide: allow, challenge, or deny"]
  R --> P
  T --> P
  W --> P
  P --> L["Event written to System Log"]

Step by step

Timing is a hidden detail

Device facts can change between sign-ins. A laptop might receive a system update, or lose its management status. Okta may use recent information rather than checking everything live each time, so a change may take a little while to show. Plan for a short delay between an event on the device and its effect on policy.

A laptop and a phone are very different machines. Device trust has to respect that.

Computers running Windows or macOS, and phones and tablets running iOS or Android, each have their own ways of reporting facts and being managed. Okta’s device features therefore work somewhat differently on each platform. At a basic level, the same ideas apply everywhere: register the device, learn whether it is managed, and check its health.

Computers versus phones in practice

Company laptops are usually owned and managed by the company, so management status and health checks are simple to apply. Phones are more mixed. Some are company-owned, but many are personal, and people expect privacy on them. A good design asks less of personal phones, checking basics such as screen lock and system version, and keeps deep control for company-owned machines.

How can Okta tell that it is really the same device returning, and not a copy? The answer is a secret that never leaves.

When a device registers, it creates a pair of linked secrets. One part is private and stays safely on the device. The other part, the public part, is given to Okta. Later, when Okta wants to confirm the device, it sends a question that only the private part can answer. Okta checks the answer with the public part. If it fits, Okta knows the same device is back.

Why this beats a simple label

A simple label, such as a device name, can be copied or faked by anyone. A secret that cannot leave the device cannot be copied in the same way. Modern devices often store such secrets in special protected hardware, which makes extraction very hard. That is why device-bound secrets are a strong basis for trust.

Certificates, simply put

Some designs use a certificate, which is a digital document that says “this device belongs to this company”. A management system can place a certificate on each managed device. When the device connects, it shows the certificate, and the receiving system checks that a trusted company issued it. A certificate is therefore another way to prove management and identity.

Device trust can make sign-in easier, not only safer. FastPass is one example of that idea.

Okta FastPass is a feature in Okta’s app on the device that can let a person sign in without typing a password, by using the device itself as a strong proof. Because the app is already registered and holds a device-bound secret, Okta can recognize the device and, with a quick fingerprint or face check on the device, accept the sign-in as strong.

Why it fits device trust

FastPass works because Okta already trusts the device. The device’s secret proves what the machine is. The fingerprint or face check proves who the person is. Together they form a strong sign-in with very little effort. This is a good example of device trust helping both security and convenience at the same time.

Combining with device assurance

A policy can say that a sign-in is acceptable only if the device passes assurance checks and the person unlocks it with a biometric. This stacks several strong signals into one easy action. The person sees a quick prompt, while the system verifies the machine, its health, and the person all at once.

Who owns a device changes what you can fairly ask of it.

A company-owned device belongs to the company. The company can configure it, monitor it, and take it back. A personal device belongs to the person, and is sometimes called BYOD, short for bring your own device. People use personal devices for convenience, and companies allow it to save cost. But the company has far less right, and far less ability, to control such a machine.

Respecting privacy

On personal devices, trust must be built with respect. People are rightly wary of any program that watches their private photos or messages. A good design collects only the facts needed for policy, such as the system version and whether a screen lock exists. It tells people clearly what is collected, and why. This honesty builds acceptance and reduces complaints.

Policies for a mixed fleet

Some devices will never be managed. A kind and clear plan for them avoids support chaos.

Contractors, visitors, and people using borrowed machines will always exist. If your rules simply say “unmanaged devices are denied”, you will meet constant complaints and risky workarounds. A better approach is to offer a lower, safer level of access for those devices, with clear messages about how to gain more.

Options for untrusted devices

Choosing by sensitivity

Messages matter

When access is refused because of the device, the message should say why and what to do. “Access denied” teaches nothing, and creates a ticket. “This app needs a company-managed device. Please use your work laptop, or contact the help desk to request one” lets people fix the problem themselves and keeps support calm.

A good plan turns a clever idea into something people can safely rely on.

Device trust touches many teams at once. The identity team owns Okta. The endpoint team owns the management system. Security reviews the risks. The help desk answers the calls. Communications explains the change to staff. Without a plan that names each team, the project stalls in the gaps between them.

Who does what

A project timeline in simple stages

The power of observing first

The most valuable early step is to watch without enforcing. By collecting device facts before any rule blocks anyone, you learn how many devices are registered, how many are managed, and how many would fail the health rules. This turns guesses into numbers, and lets you plan help for the people who will need it.

The best device policy on paper fails if people dislike living with it.

People accept security when it is clear, quick, and fair. They resist it when it blocks them without warning or explanation. Device trust changes what people can do from which machine, so every change is felt by real people at real desks. Planning the human side is half the project.

What a good experience looks like

Communication plan

Keeping the user’s trust while you keep the company safe

A device trust program succeeds when people believe it is fair. Share the reasons for each rule in plain words. Share the numbers too, such as how many devices passed the first check and how many needed help. When people see that the rules are applied evenly and that help is easy to find, they become partners in keeping devices healthy, instead of looking for ways around the checks.

It also helps to celebrate small wins. When the share of updated devices rises, or when the help desk reports fewer registration problems, tell the staff. A short message of thanks costs nothing, and keeps goodwill high for the next change.

Sooner or later a device will go missing or be found infected. A calm plan makes it a small event.

When a laptop is left on a train, or a phone is stolen, the risk is that someone else may use the trust that device holds. Because a registered device may be allowed smoother access, the company must be able to cancel that trust quickly. The same applies when a device is found to be infected with malicious software.

A response routine

A list of devices that nobody tidies becomes a list of old, forgotten trust.

Okta keeps an inventory of the devices it knows. Each entry shows the device, its owner, its status, and the facts Okta has learned. Over time, people replace laptops, reinstall apps, and leave the company. Without care, the inventory fills with devices that no longer exist but still look trusted.

The life of a device entry

Tidy habits

Why tidiness is a security matter

A stale entry is a possible door. If a former employee’s old laptop is still registered, and the account is somehow reactivated, that machine may be trusted again. Old entries also make reports misleading, since a count of “managed devices” that includes ghosts overstates real coverage.

Device trust is a security control. A weak design turns it into a false sense of safety.

Device trust adds a valuable layer, but it is not magic. Attackers study how companies use device signals and look for gaps. A careful design assumes that some devices will lie, some checks will fail, and some people will find workarounds. It layers defenses so that no single weakness opens the door.

The main risks

Protective habits

Checking devices means collecting information about people’s property. Doing it respectfully is both right and practical.

Device facts can reveal something about a person, such as which phone they own or where they sign in. A fair design collects only what it needs, uses it only for the stated purpose, and keeps it only as long as required. This is sometimes called data minimization, and it lowers both risk and worry.

Principles to follow

Fairness in practice

Device rules should not quietly disadvantage some groups. People who cannot afford a recent phone, or who work in places where only older machines are available, may fail strict health rules for reasons outside their control. Consider such cases when setting requirements, and offer alternatives, such as a loaner device or a secure virtual desktop.

You cannot manage what you cannot see. A few steady signals show whether device trust is healthy.

Monitoring means watching a system’s health so that you hear about trouble before your users do. Logging means keeping a written diary of what happened. For device trust, the diary records registrations, status changes, policy decisions, and failures. Okta’s System Log is the main place to read it, and the device inventory shows the current state.

Where to look

Metrics worth tracking

Alerts that earn their keep

Set alerts for events that need a human: sudden jumps in device-related denials, failure of the management integration, many new registrations for one account, and registration of devices from unusual places. Keep the list short, so that every alert still feels important.

Instead of memorizing errors, learn a method: find how the device was classified, then ask why.

Almost every device trust problem is a version of “the device was classified differently than I expected”. The method is to find the device, read its status, read the rule that applied, and compare. Always ask what changed recently, since most surprises follow an update, a policy edit, or a change in the management system.

Walkthrough 1: A managed laptop is treated as unmanaged

Walkthrough 2: A healthy device fails a health rule

Walkthrough 3: A person cannot register a device

Walkthrough 4: Many people are denied at once

When many people fail at the same time, suspect something shared. Look for a recent policy change, a new health requirement, an operating system release that devices have not yet reached, or a failure of the management integration. Roll back the latest change if you can. A sudden group failure is rarely about the people.

No design is perfect. Here is an honest scorecard for device trust.

Key trade-offs in plain words

A pattern is a proven way of solving a repeating problem. An anti-pattern is a popular mistake.

Patterns that work

Anti-patterns to avoid

A short field guide of habits that save time and avoid late-night incidents.

Best practices, in order of when you meet them

Mistakes that appear again and again

When auditors visit, they ask how you control the devices that reach your systems. Device trust is part of the answer.

Compliance means following rules set by law, customers, or the company itself. Many frameworks for security and privacy expect companies to know which devices access sensitive data, to protect them with encryption and updates, and to be able to remove access when a device is lost. Governance is the set of habits and records that let you show that these controls exist and work.

Evidence auditors often ask for

Governance habits that help

Retention and records

Auditors may ask for records from many months back. Built-in log history is limited, so copy key logs to your own long-term storage for the length of your audit period. Keep the records of exceptions and device removals as well, since they show that the process is followed in real life, not only on paper.

Here are four common situations where device trust earns its place. The companies are fictional teaching examples.

Public facts that give context

Security agencies and standards bodies around the world encourage organizations to know and protect the devices that reach their data, a view closely tied to the zero trust approach. Okta, founded in 2009, built its business on connecting people to applications securely, and its device features are part of that work. The detailed setups of specific customers are not public, so the stories above remain fictional.

Quick answers to the questions that come up most often.

The whole guide in one place.

Device trust lets Okta consider the machine as well as the person. By learning whether a device is known, managed, and healthy, and by letting policies act on that knowledge, a company can open sensitive doors only to machines it trusts, while keeping everyday access smooth. It is a strong layer, and it works best alongside strong sign-in proofs.

A mental model to carry with you

When any device question lands on your desk, sort it into one of four buckets. The first bucket is knowledge: does Okta know this device, and is it linked to the right person? The second bucket is control: does the company manage it? The third bucket is health: does it meet the rules for updates, encryption, and screen lock? The fourth bucket is decision: what does the policy do with all of that?

Most confusing situations turn out to be a mix-up between buckets. A device that is missing from the inventory is a knowledge problem. A laptop wrongly treated as personal is a control problem, often a broken link to the management system. A healthy-looking device that is refused is a health problem, often a version number or stale information. An unexpected denial for a well-known device is a decision problem, such as a rule in the wrong order. Naming the bucket first tells you which logs to open and which team to call.

This model also helps when you explain the design to others. Managers care about decision because it is about risk. Endpoint teams care about control and health because they are about the machines. Support teams care about knowledge because it explains most registration complaints. A good identity architect speaks to all of them and keeps the plan written down.

A final word on the people behind the devices

Behind every device is a real person trying to start their day, reach the tools they need, and get on with their work. Security that ignores this reality gets bypassed, resented, or quietly switched off. Security that respects it, by being clear, fair, and forgiving of honest mistakes, earns trust and keeps working for years.

For device trust, this means three promises. First, make the common path smooth, so that people on healthy, familiar devices barely notice the checks. Second, make the risky path firm but kind, so that unusual devices meet a clear message and a way forward. Third, make the whole design easy to explain, so that a new colleague can read it in an afternoon and understand why each choice was made.