Once the incoming records are merged into an aggregate form, the Trust Inferer is notified to trigger reevaluation of the device. This analysis references a variety of fields and aggregates the results in order to assign a Trust Tier.

The Trust Inferer currently references dozens of fields, both platform-specific and platformagnostic, across various data sources; millions of additional fields are available for analysis as the system continues to evolve.

For example, to qualify for a high Trust Tier, we might require that a device meets all (or more) of the following requirements:

This precomputation reduces the amount of data that must be pushed to the gateways, as well as the amount of computation that must be expended at access request time. This step also allows us to be confident that all of our Access Proxy
are using a consistent data set. We can make trust changes even for inactive devices at this stage.

For example, in the past, we denied access for any devices that may have been subject to Stagefright before such devices could even make an access request. Precomputation also provides us with an experiment framework in which we can write pre-commit tests to validate changes and canary small-percentage changes to the policy or Trust Inferer without impacting the company as a whole.

Of course, precomputation also has its downsides and can’t be relied on completely. For example, the Access Control Policy may require real-time two-factor authentication, or accesses originating from known-malicious netblocks may be restricted.

Somewhat surprisingly, latency between a policy or device state change and the ability of gateways to enforce this change hasn’t proven problematic. Our update latency is typically less than a second.

The fact that not all information is available to precompute is a more substantial concern.