liveBook · Manning

Managed device

As explained in Authorization in Action

A managed device is a device whose security state and configuration are administered and verifiable by an organization.

A managed device is one whose security state and configuration an organization administers and can verify. In access decisions, management becomes a condition alongside identity, clearance, time, and on-call status. section 6.2.1 section 13.3.3

Deployment access after hours

An engineer may deploy from a managed device during business hours when sufficiently cleared. At 10 p.m., the request also requires on-call status; an unmanaged device fails the baseline requirement regardless of the engineer’s other attributes. section 6.2.1

Managed-device requirements support zero-trust authorization when policy engines evaluate them at request time. For employees, a policy enforcement point can verify an identity token together with a signed posture token; customer-managed devices may instead rely on the customer’s identity provider and tenant-scoped authorization. section 9.0 section 13.3.3

Table 6.3 Attribute evaluation matrix for ABAC-based deployment access at ACME Corp

Scenario

clearance_level

device_managed

hour_of_day

on_call

Decision

Engineer deploying at
10 p.m., on call

High

true

22

true

Allow

Engineer deploying at
10 p.m., not on call

High

true

22

false

Deny

Engineer deploying at
2 p.m.

Medium

true

14

false

Deny

Engineer deploying at
2 p.m.

High

true

14

false

Deny

Engineer deploying at 10 a.m. on a managed device

High

true

10

false

Allow

Compare clearance, device management, time, and on-call status across deployment requests to see how layered policy produces allow or deny decisions. section 6.2.1

How Authorization in Action covers it

How deep it goes
Explains layered policy evaluation and signed posture verification, but stops short of device-fleet management procedures.
Examples
Uses ACME deployment decisions, employee administration, support escalation, and cross-tenant operations as concrete access scenarios.
What it assumes
Builds on identity tokens, authorization policy, and organizational device control; does not teach device-fleet management.
What you can do after
Apply it via ABAC or Cedar policies that require verified organizational device status alongside identity and contextual attributes.
How it connects
Connects device posture with ABAC, zero-trust authorization, identity providers, policy enforcement points, and Cedar.

Also explained in

Compare how 2 books explain managed device →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Authorization in Action. The section links point to the parts of the book it draws on.