A strong password on a weak device is a strong lock on a flimsy door.

For many years, companies protected themselves by guarding the network edge. If you were inside the office, you were trusted. Today people work from homes, cafes, airports, and shared offices, using laptops, phones, and tablets that may belong to the company or to the person. The edge has dissolved. What remains is a simple question for every request: who is asking, and from what?

Four problems device trust helps solve

• Stolen credentials: an attacker who steals a password still faces a device check they cannot satisfy from their own machine.
• Unhealthy devices: a laptop with no disk encryption, out-of-date software, or no screen lock is a risk to the data it touches.
• Unknown devices: data should not flow freely to personal machines that the company cannot manage or wipe.
• Mixed fleets: companies run many operating systems and many ownership models, and need consistent rules across them.

Not all-or-nothing

Device trust is rarely a simple yes or no. Most organizations use shades. A managed and healthy device gets smooth access. A personal device might get limited access to less sensitive applications, perhaps with extra proof. An unknown device might get nothing, or only a web-based view with no downloads. The art lies in matching the level of trust demanded to the sensitivity of the application.

Who feels the benefit

Security teams gain confidence that sensitive data reaches only healthy, known devices. Employees on trusted devices enjoy smoother sign-in, with fewer prompts. Helpdesk teams see fewer incidents caused by compromised accounts. Auditors gain clear evidence of control over how company data is accessed. Naming these groups early helps you explain the project to each of them in the terms they care about.

A small set of words appears again and again. Learn them once and the rest reads easily.

Managed versus registered

These two words are often confused. A registered device is one Okta has seen and recorded, usually when the person installed an app and signed in on it. A managed device is one that the company’s management tool controls. A device can be registered without being managed, as in the case of a personal phone. The most trusted devices are both registered with Okta and managed by the company’s tool, with Okta able to confirm the link between the two.

Compliance and health

Management tools also judge whether a device is compliant with company rules, such as having a screen lock, disk encryption, a minimum operating system version, and no signs of tampering. Okta can use compliance as a signal when deciding access. A device that is managed but non-compliant may be treated differently from one that is managed and compliant.

flowchart TD
    D["Device"] --> R{"Known to Okta?
registered"}
    R -->|"no"| U["Unknown device"]
    R -->|"yes"| M{"Controlled by company
management tool?"}
    M -->|"no"| P["Registered, unmanaged
often personal"]
    M -->|"yes"| C{"Meets health rules?
compliant"}
    C -->|"no"| N["Managed, not compliant"]
    C -->|"yes"| T["Managed and compliant
highest trust"]
    

Figure 1 shows the ladder. Each step up adds confidence. Rules in Okta can ask for different steps on different applications, so that a casual application accepts any registered device while a sensitive one demands the top step.

Why words matter in this topic

Teams often use the words managed, enrolled, registered, trusted, and compliant as if they meant the same thing. They do not. Before any project meeting, agree on definitions and write them on a shared page. Misunderstandings about words cause real mistakes in rules, such as treating every registered device as if it were company-controlled. A shared glossary is cheap and prevents expensive confusion.

Device checks are part of the rules that decide whether a sign-in succeeds and what proof is needed.

In Okta, access decisions are made by policies attached to applications. These authentication policies contain rules that look at conditions, such as the user’s group, the network, the risk level, and the device, and decide what is required. Device conditions are one input among several. They let you say, for example, “For this application, require a managed device, or else require stronger proof.”

flowchart LR
    S["Sign-in request"] --> P["Authentication policy
for the application"]
    I["Identity facts"] --> P
    DV["Device facts"] --> P
    N["Network facts"] --> P
    RK["Risk facts"] --> P
    P --> O{"Outcome"}
    O --> A["Allow"]
    O --> X["Require stronger proof"]
    O --> B["Deny"]
    

Figure 2 shows that device trust is not a separate gate. It is one set of facts that the policy considers together with the others. This is powerful, because it lets you design balanced rules rather than rigid ones.

Two engines, one idea

Okta has more than one generation of its sign-in engine, and device features have evolved across them. Older approaches relied heavily on certificates delivered to devices. Newer approaches rely on an Okta app on the device, together with device assurance rules and signals from management tools. The ideas in this guide apply to both, but the exact steps differ. Confirm which engine your organization uses and read the matching documentation.

Not every application needs the same treatment

A company canteen menu and a payroll system do not need the same protection. Device trust is most valuable where data is sensitive, and least valuable where data is public. Applying heavy device rules everywhere increases friction without reducing risk much. Concentrate on the applications where a stolen password would hurt most, and use lighter rules elsewhere.

To integrate with them, you must first understand what they bring to the table.

A device management tool is a service that a company uses to control its fleet. It reaches devices through built-in management features of their operating systems. Once a device is enrolled, the tool can send it settings, install and remove apps, check its state, lock it, or erase it. It also holds a record of every enrolled device.

Typical abilities

• Enrollment: bring a device under management, often during first setup.
• Configuration: push settings such as Wi-Fi, passcode rules, and encryption requirements.
• App distribution: install required applications and remove unwanted ones.
• Compliance checking: judge whether a device meets company rules and flag those that do not.
• Remote actions: lock a lost device, wipe company data, or erase everything.
• Inventory: list devices, owners, operating system versions, and hardware details.

Why they matter to Okta

Okta can learn about a device on its own, from the Okta app and from the device’s operating system. But only the management tool knows whether the company actually controls the device and whether it meets company rules. By connecting the two, Okta can base access decisions on the management tool’s knowledge.

flowchart LR
    ADM["IT administrators"] --> MDM["Device management tool"]
    MDM -->|"settings, apps, rules"| DEV["Company devices"]
    DEV -->|"state and health"| MDM
    MDM -.->|"management and compliance signals"| OKTA["Okta"]
    DEV -->|"Okta app and sign-in"| OKTA
    

Figure 3 shows two relationships. The management tool controls devices and hears from them. Okta talks to devices through sign-ins and the Okta app, and it receives signals from the management tool. Combining both views yields much stronger decisions than either alone.

Understand what your tool can and cannot report

Management products differ in the facts they collect, how often they update, and how they judge compliance. Before building rules, read what your tool actually records and how fresh it is. A rule that depends on a fact the tool does not report, or reports only once a day, will cause confusion. Ask the endpoint team to describe the tool in plain words, including its weak spots, and write down the answers.

Several sources of knowledge, each with different strengths, feed device trust decisions.

Why several sources help

No single source is perfect. The Okta app sees the device from the inside but depends on the operating system’s honesty. The management tool knows about control but may lag behind real changes. Certificates are strong proof of enrollment but do not prove current health. Using more than one source, and favouring stronger ones for sensitive applications, produces robust decisions.

flowchart TD
    A["Okta app on device"] --> DEC["Device trust decision"]
    B["Certificate from management tool"] --> DEC
    C["Management tool signal"] --> DEC
    D["Device assurance checks"] --> DEC
    E["Endpoint security signal"] --> DEC
    DEC --> OUT["Level of trust for this sign-in"]
    

Figure 4 shows how sources combine. Each adds a piece of evidence. The more evidence agrees, the more confident the decision. When sources disagree, the policy decides which to believe and what to do.

Choosing which sources to rely on

For ordinary applications, registration and basic checks may be enough. For sensitive ones, combine at least two independent sources, such as management status and a health check. Independent sources fail in different ways, so agreement between them is stronger evidence than either alone. Write down, for each tier of application, which sources are required.

Registration is the first step. It gives Okta a lasting memory of a device.

When a person installs the Okta app on a device and signs in, the app can create a link between the person and the device, called registration. The device gets a unique identity that Okta recognizes in future. After registration, Okta can tell whether a sign-in comes from a known device or a new one, and can make the sign-in smoother because the device itself becomes part of the proof.

What registration gives you

• Recognition: returning devices are recognized, new devices are treated with more care.
• Smoother sign-in: the device can serve as a strong, hard-to-phish authenticator.
• Inventory: administrators can see which devices are linked to which people.
• Revocation: a lost or stolen device can be unlinked.

Registration is not management

A personal phone with the Okta app is registered but is not managed by the company. Registration alone proves little about the health or ownership of the device. It is a foundation, not a conclusion. That is why many organizations add management signals for their most sensitive applications.

sequenceDiagram
    participant P as Person
    participant D as Device
    participant A as Okta app
    participant O as Okta
    P->>D: Install Okta app
    P->>A: Sign in
    A->>O: Create device identity
    O-->>A: Registered
    Note over O: Device is now known and linked to the person
    P->>D: Later sign-in
    D->>O: Present device identity
    O-->>D: Recognized device
    

Figure 5 shows registration as a one-time setup that pays off on every future sign-in. The device identity becomes part of the proof, so that later sign-ins are smoother and safer at the same time.

Encouraging registration

Registration works only if people actually install the app and sign in. Make it easy. Deploy the app automatically on managed devices, give clear instructions for personal devices, and explain the benefit in simple terms, such as faster sign-in and better protection of their account. Track registration numbers and follow up with teams that lag behind.

The integration lets Okta recognize which devices your company manages.

Okta supports integrations with several popular device management products, and offers general approaches for others. The details differ by product, so this chapter explains the shape of the work rather than exact clicks.

The common shape of an integration

Two teams, one project

This work spans two groups that often sit in different parts of the company: identity administrators who run Okta, and endpoint administrators who run the management tool. Neither can finish alone. Set up a joint working group, share a plan, and agree on who changes what and when. Many device trust projects stall because each team assumed the other would handle a step.

flowchart LR
    ID["Identity team
Okta"] --> PLAN["Shared plan"]
    EP["Endpoint team
management tool"] --> PLAN
    PLAN --> PILOT["Pilot group"]
    PILOT --> CHK{"Pilot devices
show as managed?"}
    CHK -->|"no"| FIX["Fix profiles or integration"]
    FIX --> PILOT
    CHK -->|"yes"| WAVES["Roll out in waves"]
    

Figure 6 stresses collaboration. The pilot step is a loop: nothing proceeds until pilot devices correctly show as managed. Time spent here saves far more time later.

Keeping the integration healthy

An integration is not finished when it first works. Credentials used by the link may expire, tool versions may change, and settings may be edited by someone unaware of the link. Assign an owner, monitor the link’s status, and test it after every upgrade of either system. A broken link may fail silently, making managed devices look unmanaged until someone notices.

One long-standing approach uses a digital identity document installed on the device by the management tool.

A certificate is a small digital file that acts as an identity card for a device. In certificate-based device trust, the management tool delivers a certificate to each enrolled device. When the device signs in, it presents the certificate. Okta checks that the certificate was issued by a source it trusts, and from this concludes that the device is managed by the company.

How the certificate gets there

The management tool uses a standard enrollment process in which the device generates its own secret and requests a certificate, so that the secret never leaves the device. This is a strong design because stealing the certificate file alone is not enough. The secret part stays protected on the device, often in dedicated secure hardware.

Strengths and weaknesses

sequenceDiagram
    participant M as Management tool
    participant D as Device
    participant O as Okta
    M->>D: Enroll and request certificate
    D->>D: Create secret in protected storage
    D-->>M: Certificate request
    M-->>D: Signed certificate
    D->>O: Sign in presenting certificate
    O->>O: Check issuer is trusted
    O-->>D: Treated as managed
    

Figure 7 shows the flow. The tool vouches for the device by issuing a certificate, and Okta trusts the tool’s vouching. The weak points are expiry and renewal, so plan monitoring for certificates nearing their end date.

Planning certificate lifetimes

Certificates have a start and an end date. Short lifetimes limit the damage if one is stolen but require reliable renewal. Long lifetimes reduce renewal work but increase risk and the chance that everyone forgets the date. Choose a lifetime that your automation can renew reliably, test renewal on a pilot group, and set alerts well before the end date.

Newer approaches let the management tool tell Okta directly about a device’s status.

Instead of relying only on certificates, Okta can connect to the management tool and ask or be told whether a device is managed and whether it meets the company’s compliance rules. When a person signs in from a device, Okta recognizes the device through the Okta app, looks up the matching record in the management tool, and uses the result in the policy decision.

The matching problem

For this to work, Okta must correctly pair its record of a device with the management tool’s record of the same device. Both need a shared identifier, such as a hardware serial number or a unique device identifier. If the identifiers do not match, the device looks unmanaged even when it is not. Making sure identifiers line up is one of the most important parts of the project.

Freshness of the signal

Compliance status changes over time. A device may be compliant in the morning and become non-compliant after a setting change in the afternoon. The management tool may only update its records on a schedule, and Okta may only refresh its view periodically. This delay means that signals can be a little behind reality. Decide how much delay is acceptable for each application, and use shorter session lifetimes for sensitive ones.

flowchart TD
    SI["Person signs in on device"] --> ID["Okta recognizes device
by its identity"]
    ID --> MT["Look up the same device
in management tool"]
    MT --> Q{"Match found and
device compliant?"}
    Q -->|"yes"| P1["Managed and compliant"]
    Q -->|"found, not compliant"| P2["Managed, not compliant"]
    Q -->|"no match"| P3["Unmanaged"]
    

Figure 8 shows the lookup. Three outcomes are possible, each of which policies can treat differently. The “no match” outcome deserves attention: it may mean the device is unmanaged, or it may mean the identifiers failed to pair.

Handling devices that rarely connect

Some devices, such as laptops in storage or tablets in a cupboard, seldom report to the management tool. Their records can become stale, and compliance data may be days or weeks old. Decide what to do with stale records: treat them as unknown, require a fresh check-in, or flag them for follow-up. A clear rule avoids arguments when a long-absent device returns.

Device assurance lets you write plain rules about device health and apply them to policies.

A device assurance policy is a named set of requirements about a device, such as a minimum operating system version, disk encryption turned on, a screen lock set, and certain security features present. Different operating systems have their own policies because their features differ. Once defined, an assurance policy can be referenced in authentication rules, so that only devices that meet the requirements can pass.

Common requirements

Setting sensible thresholds

A requirement that no device meets is useless, and one that nearly all devices meet is pointless. Examine your fleet first. Set minimum versions that most healthy devices already satisfy, and raise them gradually. Give people notice and a way to update before the rule blocks them.

flowchart TD
    DV["Device facts reported"] --> CK{"Meets assurance policy?"}
    CK -->|"all requirements met"| PASS["Pass"]
    CK -->|"some unmet"| FAIL["Fail with reason"]
    FAIL --> GUIDE["Tell the person what to fix"]
    GUIDE --> RE["Re-check after fix"]
    RE --> CK
    

Figure 9 emphasizes the human side. A failed check is only useful if the person knows what to do next. Clear messages and a quick re-check turn a blocked person into a fixed device.

Keeping assurance rules understandable

Give each assurance policy a name that describes its purpose, such as one for finance laptops or one for standard phones. Add a plain description listing every requirement and the date of the last review. A reviewer should be able to read it in a minute and understand exactly what it demands and why.

Rules turn device facts into decisions. Keep them few, clear, and ordered with care.

In an authentication policy, each rule describes a situation and what to require. Device conditions might include whether the device is registered, whether it is managed, and whether it meets a named assurance policy. Rules are checked from top to bottom, and the first rule that matches decides the result. Order is therefore essential.

An example in words

Guidelines

• Most specific first: put narrow, high-trust rules above broad, low-trust ones.
• End with a clear default: do not leave the final decision ambiguous.
• Name rules plainly: a rule’s name should say what it does, so reviewers understand it.
• Pair denial with guidance: a denied person should learn what to do next.
• Test with real devices: each rule should be tried with devices in each state.

flowchart TD
    R["Request"] --> A{"Rule 1:
managed and compliant?"}
    A -->|"yes"| A1["Allow, strong device proof"]
    A -->|"no"| B{"Rule 2:
registered only?"}
    B -->|"yes"| B1["Allow with extra proof,
limited access"]
    B -->|"no"| C["Rule 3:
deny with guidance"]
    

Figure 10 shows a simple three-step ladder. The most trusted devices pass first and enjoy the easiest experience, partially trusted devices get limited access, and the rest are refused with help.

Testing rule order

Order mistakes are among the most common causes of surprising results. After any change, walk each device state through the rules from top to bottom and record which rule matches. Keep a short table of expected matches. A rule placed too high can swallow devices meant for a later rule, and a missing default can leave gaps.

Personal devices are the hardest case. They are useful and cannot be fully controlled.

Many people prefer to use their own phones and laptops for work. Companies often allow this because it saves money and pleases staff, but it raises questions about privacy and control. A company usually cannot, and should not, take full control of a personal device. Yet it still wants some protection for company data.

Typical approaches

Respect privacy

Be clear with staff about what the company can and cannot see or do on a personal device. Explain, in plain words, that management applies only to the work area where the design supports it. Trust and clear communication determine whether people enroll willingly.

Match access to trust

A sensible pattern is to grant full access only to managed, compliant company devices, limited access to personal devices with a work area or app protection, and web-only access with extra proof to registered personal devices. Unknown devices get nothing or only the lowest-risk applications.

flowchart LR
    CO["Company-owned,
fully managed"] --> F["Full access"]
    PW["Personal with
work profile"] --> L["Limited access"]
    PR["Personal,
registered only"] --> W["Web access with extra proof"]
    UN["Unknown device"] --> N["No access or lowest risk apps"]
    

Figure 11 summarizes the principle. The less control the company has, the less access it grants. This approach respects personal privacy and protects company data at the same time.

Offboarding personal devices

When people leave, work data on personal devices must go too. Where a work area exists, the company can remove just that area. Where only registration exists, revoke the registration and end sessions. Confirm that leavers are removed from both systems as part of the standard departure checklist, since personal devices are easy to forget.

Seeing all the parts at once makes planning and troubleshooting easier.

A device trust setup involves several cooperating parts. Knowing who does what helps you place each control correctly and know where to look when something fails.

flowchart LR
    DEV["Device"] --> APP["Okta app"]
    APP --> OK["Okta"]
    MDM["Management tool"] -->|"enroll, configure"| DEV
    MDM -.->|"managed and compliance signals"| OK
    CA["Certificate authority"] -.->|"device certificates"| DEV
    EDR["Endpoint security tool"] -.->|"protection signal"| OK
    OK --> POL["Authentication and
device assurance policies"]
    POL --> APPS["Applications"]
    OK --> LOG["System log"]
    

Figure 12 draws the picture. The device is at the left, supported by the management tool. Okta receives facts from the device, from the management tool, and optionally from a certificate authority and security tools. Policies combine these facts and decide on access to applications. Everything is recorded in the log.

Where problems tend to arise

Most failures occur at the joints between parts: a profile that never reached the device, a certificate that expired, a mismatched identifier, a signal that arrived late, or a policy that checks the wrong condition. Knowing the joints tells you where to look first.

Plan for failure of a component

Think about what happens if the management tool is unreachable, if a signal source is slow, or if a certificate authority fails. Decide in advance whether policies should fail open, allowing access with extra proof, or fail closed, denying access. For most ordinary applications, a short failure should not stop work. For the most sensitive ones, a cautious default is appropriate.

Laptops and desktops are the workhorses of most companies. They have their own considerations.

Typical building blocks

• Okta app: installed on the device, often by the management tool, to register it and take part in sign-in.
• Management enrollment: the device is enrolled in the company’s management tool, usually at first setup.
• Settings profiles: deployed by the management tool to enforce encryption, screen lock, and updates.
• Secure hardware: modern laptops contain protected chips that can hold secrets safely.

Common patterns

Operating system differences

Windows and macOS expose different facts and use different management features. Policies should be written for each separately, with equivalent intent but different checks. Do not assume that a rule for one operating system works the same way on the other, and test each.

flowchart TD
    NL["New laptop"] --> EN["Enroll in management tool"]
    EN --> PR["Profiles: encryption, lock, updates"]
    EN --> AP["Install Okta app"]
    AP --> RG["Register with Okta"]
    PR --> CP["Compliance evaluated"]
    RG --> TR["Trusted for sign-in"]
    CP --> TR
    

Figure 13 shows the happy path for a new device. Automating these steps during first setup reduces mistakes and gives the company trust in each device from day one.

Updates and patching

Desktop operating systems release updates often, and assurance rules that demand recent versions can suddenly fail a large share of devices. Coordinate with the endpoint team on update schedules, give staff time to install updates, and consider a grace period after each new release before the minimum version rises.

Phones and tablets are personal, always with us, and a prime target for loss and theft.

Mobile operating systems have built-in management frameworks that management tools use. They also have strong app separation. Mobile device trust often involves delivering the Okta app and its settings through the management tool, and using either a managed device or a protected work area to separate company data from personal data.

Common mobile situations

Lost and stolen phones

Phones get lost far more often than laptops. Prepare a clear procedure: report quickly, revoke the device’s registration in Okta, end its sessions, and where managed, lock or wipe it through the management tool. Practice this procedure so that it takes minutes, not hours.

sequenceDiagram
    participant P as Person
    participant H as Helpdesk
    participant O as Okta
    participant M as Management tool
    P->>H: Report lost phone
    H->>O: Revoke device registration and sessions
    H->>M: Lock or wipe if managed
    M-->>H: Confirmation
    O-->>H: Sessions ended
    H-->>P: Guidance for replacement
    

Figure 14 shows the two halves of the response. Okta ends the device’s ability to sign in, and the management tool protects the data on it. Doing both is important, because each covers what the other cannot.

Mobile operating system updates

Each year brings new mobile operating system versions, and older phones eventually stop receiving updates. Decide how you will treat devices that can no longer be updated. A clear retirement policy, supported by device replacement budgets, prevents a growing tail of unsupportable phones in your fleet.

Protection products add another view of a device’s health.

Endpoint security products watch devices for malware, suspicious behaviour, and signs of compromise. Okta can accept signals from some of these products, such as an assessment of whether a device looks safe or at risk. These signals can be used in policies, for example to require extra proof or deny access when a device is flagged as high risk.

What this adds

• Dynamic health: a device that was fine this morning but is now infected can be treated differently immediately.
• Evidence beyond configuration: a device can be correctly configured and still compromised. Security tools see behaviour.
• Response automation: a flagged device can be cut off from sensitive applications without human delay.

Cautions

Signals can be wrong. A false alarm that blocks a senior executive before a board meeting creates pressure to disable the feature. Start by using the signal to require extra proof rather than to deny, review the results, and tighten only with evidence. Also check how quickly signals arrive, and what happens if the security tool is unavailable.

flowchart LR
    SEC["Endpoint security tool
watches the device"] -->|"risk signal"| OK["Okta"]
    MDM["Management tool"] -->|"compliance signal"| OK
    OK --> POL{"Policy"}
    POL -->|"low risk and compliant"| A["Allow"]
    POL -->|"medium risk"| X["Extra proof"]
    POL -->|"high risk"| D["Deny and notify"]
    

Figure 15 shows a graded response. Low risk passes, medium risk is challenged, and high risk is refused. Having a middle option avoids the all-or-nothing trap.

Avoiding alert fatigue

Security products can generate large numbers of signals. Sending all of them to access rules creates noise and unnecessary blocks. Agree with the security team which signal levels should change access decisions, and keep the rest for investigation. A short list of meaningful triggers is better than a long list that people learn to ignore.

A good rollout earns trust. A bad one is remembered for years.

Communication is half the job

Staff should hear about the change several times, in plain words: why it is happening, what they must do, how long they have, and where to get help. Include simple step-by-step guides for each device type. People forgive inconvenience that was explained and resent inconvenience that was a surprise.

flowchart LR
    A["Take stock"] --> B["Register devices"]
    B --> C["Observe only"]
    C --> D["Warn people"]
    D --> E["Extra proof"]
    E --> F["Restrict for sensitive apps"]
    F --> G["Review and support"]
    

Figure 16 shows the gentle ramp. Every step gives people time and information. Jumping directly to restriction is how organizations create angry crowds and exception requests from executives.

Measuring rollout success

Decide in advance how you will judge each stage: the share of devices registered, the share managed and compliant, the number of blocked sign-ins, the count of helpdesk tickets, and the number of exceptions. Review these numbers weekly during rollout. If tickets rise sharply, pause and fix the cause before proceeding.

Most problems fall into a few families. Work from the device outward.

A simple routine

flowchart TD
    P["Problem reported"] --> A{"Okta app
present and signed in?"}
    A -->|"no"| A1["Install or sign in"]
    A -->|"yes"| B{"Enrolled and recently
checked in?"}
    B -->|"no"| B1["Fix enrollment"]
    B -->|"yes"| C{"Paired in
both systems?"}
    C -->|"no"| C1["Fix identifiers"]
    C -->|"yes"| D{"Meets health rules?"}
    D -->|"no"| D1["Guide the person to fix"]
    D -->|"yes"| E["Check policy order and log"]
    

Figure 17 shows the layered approach. Each question rules out a family of causes. Skipping layers wastes time, so resist the urge to edit policies first.

Using the system log

Okta’s log records device-related events such as registrations, checks, and policy outcomes. When a person reports a problem, find their sign-in at the reported time and read which rule matched and why. Compare with a successful sign-in from the same person to see what differs. Most issues can be diagnosed from the log in minutes when you know where to look.

Three small stories show the thinking from problem to settled design. No code is needed to follow them.

Example 1: Protecting the finance applications

A company wants to ensure that payroll and payment applications are only reachable from company-managed laptops. The identity team and the endpoint team meet and agree that the payment application deserves the highest level of device trust. They deploy the Okta app through the management tool to all finance laptops, connect the management tool to Okta, and define a device assurance policy requiring encryption, a screen lock, and a recent operating system version. For a month, the policy only records results. The team discovers twelve laptops that are enrolled but have encryption off, and four that are not enrolled at all. They fix these, warn the affected staff, and then switch the payment application to require a managed, compliant device. Finance staff on personal phones may still approve small items in a limited mobile view, but only with extra proof.

Example 2: A merger with two management tools

Two companies merge, and each uses a different device management product. Okta must trust devices from both. The team adds both tools as sources of management information, ensures that device identifiers are consistent across the two, and writes one assurance policy per operating system rather than per tool. During the transition, rules accept devices managed by either tool, and a project plan moves all devices to one tool over a year. The assurance policies stay the same throughout, so users notice little change.

Example 3: Contractors and temporary staff

A company has hundreds of contractors who use their own laptops. Rather than enrolling those laptops in company management, the team creates a contractor group with access to a small set of web applications. The rule for contractors requires a registered device and strong proof, grants web access only, and prevents downloads. Sensitive applications refuse contractor access entirely. If a contractor needs deeper access, the company issues a managed laptop for the duration of the engagement and collects it afterwards.

flowchart TD
    N["Business need"] --> S["Classify applications
by sensitivity"]
    S --> D["Classify devices
by control and health"]
    D --> M["Match trust to sensitivity"]
    M --> O["Observe, then warn"]
    O --> E["Enforce in waves"]
    E --> R["Review and refine"]
    

Figure 18 shows the shared shape. Each story classified applications and devices, matched trust to sensitivity, observed first, and enforced gradually. The merger and contractor stories show that the same pattern adapts to complicated situations.

What the examples teach

The lessons are modest and practical. Prepare an inventory, match trust to sensitivity, observe before enforcing, and work as one team. None of the examples needed exotic technology. They needed patience, clear communication, and a willingness to fix small mismatches before they grew into large outages.

The systems that decide trust must themselves be trustworthy.

Principles to follow

The management tool as a high-value target

A tool that can configure, lock, and wipe every device is extremely powerful. If an attacker takes over its administrator account, they can push malicious software to the whole fleet or mark compromised devices as compliant. Protect it with the strongest sign-in controls you have, separate administrator accounts, limited roles, and alerts on unusual changes.

Spoofed or stolen device identities

If a device identity is a copyable file, a thief who copies it can impersonate the device. This is why identities held in protected hardware are better. Understand how each platform stores device secrets, and prefer designs where the secret cannot leave the device.

Compromised but compliant

A device can pass every configuration check and still be infected. Compliance is not proof of safety. Use endpoint security signals and behavior-based risk detection to cover what configuration checks cannot.

Privacy of device data

Device information can reveal personal details, such as location, installed apps, and usage. Collect only what policy needs, explain it to staff, and follow your privacy rules and local law, especially on personal devices.

flowchart TD
    A["Threat: management tool takeover"] --> C1["Control: strongest admin sign-in, limited roles, alerts"]
    B["Threat: copied device identity"] --> C2["Control: secrets in protected hardware"]
    D["Threat: compromised but compliant device"] --> C3["Control: endpoint security and risk signals"]
    E["Threat: stale signal"] --> C4["Control: short sessions for sensitive apps"]
    F["Threat: privacy overreach"] --> C5["Control: collect minimum and explain"]
    

Figure 19 pairs five threats with controls. None is exotic. Together they make device trust a source of real protection instead of false comfort.

Plan for the day it fails

No control works every time. Decide in advance what you will do if a compromised device gets through: force a fresh sign-in, require stronger proof, revoke the device, and investigate neighbouring activity. A rehearsed plan turns a frightening event into a procedure, and the lessons improve every layer.

Device trust is a living system. Measures show whether it is working and where to improve it.

What to measure

Helpful measures over time

• Registered devices per person: expected to grow as the Okta app spreads.
• Managed share of sign-ins: how much sign-in traffic comes from managed devices.
• Compliance failures by reason: shows which requirements cause the most trouble.
• Mismatched devices: devices seen in one system but not the other.
• Certificates nearing expiry: where certificates are used.
• Stale devices: devices that have not checked in for a long time.
• Exceptions: number, age, and owners of approved exceptions.

flowchart LR
    OK["Okta events and device list"] --> COL["Collector"]
    MDM["Management tool inventory"] --> COL
    SEC["Security tool reports"] --> COL
    COL --> DASH["Dashboards"]
    COL --> ALR["Alerts"]
    DASH --> OWN["Owners and leadership"]
    ALR --> OPS["Operations and security"]
    

Figure 20 shows that no single source tells the whole story. Okta shows sign-ins and registered devices, the management tool shows inventory and compliance, and security tools show risk. Combining them reveals gaps and mismatches.

Alerts worth having

• A sudden drop in the share of managed devices signing in.
• A spike in compliance failures after an operating system release.
• Certificates expiring within a set number of days.
• Changes to device assurance policies or to the management integration.
• A high-risk device signal for a privileged user.

Reporting to leaders

Leaders want a simple story. A one-page monthly summary showing coverage, compliance rate, exceptions, and tickets, with a few sentences of explanation, is enough. Show trends rather than single months, and call out decisions that need leadership input, such as budget for replacing unsupportable devices.

Test every device state, not only the happy one.

A test matrix

Test timelines

flowchart LR
    ST["Set device into a state"] --> TR["Try sign-in to each app"]
    TR --> OB["Observe result and message"]
    OB --> CMP{"Matches the matrix?"}
    CMP -->|"no"| FX["Adjust policy or integration"]
    FX --> ST
    CMP -->|"yes"| NX["Next state"]
    

Figure 21 shows the testing loop. Each state is tried, observed, and compared with the expected result. Only when all rows match is the design ready for wider rollout.

Repeating tests after change

Tests are not a one-time activity. After any change to policies, assurance rules, the integration, or the management tool, repeat the key checks for each device state. Keep the test matrix in a shared place and note the date of the last run. Small, frequent checks catch problems while they are cheap to fix.

Device trust spans teams. Clear ownership prevents gaps.

Routines

• Weekly: review mismatches, stale devices, and failure reasons.
• Monthly: review exceptions and the trend of coverage and health.
• On each major operating system release: review assurance minimum versions and test compatibility.
• Quarterly: review policies, integrations, and certificate dates with both teams.
• Joiner and leaver: make sure device registrations are removed and devices collected when people leave.

flowchart LR
    NEW["New device or person"] --> ENR["Enroll and register"]
    ENR --> RUN["Run: monitor compliance"]
    RUN --> RVW["Regular review"]
    RVW --> CHG["Update policies"]
    RUN --> OFF["Leaver or retired device"]
    OFF --> REV["Revoke, wipe, collect"]
    

Figure 22 shows a complete lifecycle. The retirement step is easy to forget. Devices that leave the company without revocation remain a quiet risk.

Handover and continuity

Staff change roles, and knowledge about device trust often leaves with them. Keep the runbook, the glossary, and the exception register in a shared place, and ensure at least two people in each team understand the integration. When owners leave, reassign their items explicitly.

Device trust adds real protection and real effort.

Key trade-offs

• Security versus convenience: stricter device rules protect more and inconvenience more.
• Control versus privacy: deeper management gives more control and intrudes more on personal devices.
• Freshness versus load: more frequent signals are more accurate and cost more effort.
• Uniformity versus fit: one rule for everyone is simple; tailored rules fit better and are harder to maintain.

Comparing cost and benefit honestly

The visible costs are setup effort, ongoing care for two systems, and occasional friction for users. The benefits are partly invisible: accounts that were never taken over, data that never leaked, and incidents that never happened. Because prevented problems are hard to see, track coverage and incident trends over time so the value is visible when budgets are discussed.

Teams that run device trust calmly reuse a handful of simple patterns.

flowchart TD
    P1["Trust tiers by application"] --> OUT["Calm, graded, well-understood device trust"]
    P2["Staged rollout"] --> OUT
    P3["Assurance policy per OS"] --> OUT
    P4["Graded response"] --> OUT
    P5["Shared runbook"] --> OUT
    

Figure 23 shows that the patterns reinforce each other. Tiers set expectations, staging protects people, shared assurance policies keep changes small, graded responses avoid harsh blocks, and a shared runbook keeps the two teams aligned.

Turning patterns into a standard

Many organizations capture these patterns in a short internal standard: the trust tiers, the assurance policies, the rollout stages, the exception rules, and the owners. A standard avoids reinventing decisions for each application and makes audits straightforward. Keep it short enough that people actually read it.

These habits look convenient at first and cause pain later.

Spotting anti-patterns early

Warning signs include exceptions with no end date, certificates nobody tracks, rules that nobody can explain, and two teams that rarely talk. If you see any of these, pause and apply the better approach before the problem grows. Anti-patterns usually begin as sensible shortcuts under time pressure, so correct them kindly but firmly.

This chapter gathers the habits that separate calm programs from chaotic ones.

Best practices

Common mistakes

A short pre-enforcement routine

Before turning on a restrictive rule, confirm that pilot devices of each type behave as expected, that the share of affected people is small and known, that the helpdesk has guides, that exceptions have a process, that rollback is prepared, and that leadership has agreed the date. This takes a few hours and avoids most launch-day trouble.

A short yearly review

Once a year, step back from the details. Ask whether the trust tiers still match the applications, whether assurance minimums are right, whether the integration is healthy, whether exceptions have ended, whether the personal device approach still respects privacy, and whether new threats call for stronger controls. Record the answers and the actions that follow.

Four fictional companies show how these ideas play out in practice.

flowchart LR
    I["Incident or finding"] --> L["Read the logs and inventories"]
    L --> C["Contain the effect"]
    C --> F["Fix the root cause"]
    F --> T["Retest each device state"]
    T --> R["Update runbook and monitoring"]
    

Figure 24 shows what the scenarios had in common. Each team read the evidence, contained the effect, fixed the root cause, retested, and updated their runbook and monitoring so that the same problem would be caught earlier next time.

What the scenarios share

In every story, a small amount of preparation made a large difference: a certificate dashboard, an exception with an end date, a weekly mismatch report, a rehearsed lost-phone procedure. The cost of this preparation is measured in hours, while the cost of its absence is measured in blocked staff, exposed data, and long nights. This is the central lesson of the guide.

Quick answers to the questions beginners ask most often.

Device trust adds the second half of the question: not only who, but from what. Build it patiently, in two teams, with clear messages.

We began with two visitors holding the same badge but arriving with very different equipment. We saw how Okta can tell a registered device from a managed one, how management and enterprise mobility tools bring knowledge of control and compliance, and how certificates, signals, assurance policies, and security tools combine into a level of trust. We explored policy rules, personal and mobile devices, rollout, troubleshooting, security, monitoring, testing, ownership, patterns, and pitfalls.

The craft lies in a few steady habits: know your devices, classify your applications, match trust to sensitivity, make the two teams work as one, stage the rollout, explain each change, and keep watching. Confirm Okta-specific and tool-specific details in your own consoles and the official documentation.