Summary

  • RFC 5209 defines assessment as collection of posture for a set of endpoint capabilities followed by evaluation against compliance policy. The resulting verdict is bounded by evidence, policy and time.
  • Reassessment is not an optional embarrassment after a failed design. It is a central use case because an endpoint once considered compliant can change, or policy can move around it.
  • Assessment, authorization and enforcement are different control surfaces. A global compliant result does not prove that a gateway installed a rule, that remediation ran, or that the endpoint remains compliant now.

Twenty-five minutes in the life of a green badge

At 09:00 a managed laptop answers an endpoint posture assessment. Its firewall collector reports that protection is active. Its software collector reports the required patch level. Two validators apply policy version 42. The broker combines their results and returns a global compliant decision. A network gateway grants normal access.

At 09:17 the user disables the firewall to test an application. The collector notices and emits a posture-change notification, but the local broker is restarting. The event is lost. At 09:25 the assurance screen still says compliant. Its evidence is pristine: the signed assessment record has not been edited, the session completed without error, and the original result was correct.

The screen is nevertheless making a claim nobody measured. It has converted “considered compliant at 09:00 from these observations under policy 42” into “is compliant now”.

This is a constructed scenario, not an account of an organization, product or incident. It follows the failure class RFC 5209 names directly. The document says reassessment may be needed because posture and policy change over time, and gives the example of a user disabling a required host firewall. The standard does not promise that a past green result will keep the endpoint green. It supplies the vocabulary for refusing that promise.

What the assessment actually contains

RFC 5209 is an Informational reference model and requirements document, published in 2008. It is not one universal compliance engine. It defines assessment as collecting posture for a set of endpoint capabilities so appropriate validators can evaluate that posture against policy.

Each noun narrows the result. “A set” is not necessarily every feature. “Posture” is configuration or status relevant to the organization's policy, not a full copy of reality. “Collected” means an observer obtained an attribute through a particular component. “Evaluate” introduces rules and judgment. “Policy” adds a version, owner and effective time.

The model then gives the resulting data different names. A Posture Attribute describes observed configuration or status. A Request Attribute asks for information. A Result Attribute communicates an assessment decision. A Remediation Attribute carries instructions intended to bring an endpoint into compliance. These are not interchangeable messages. An instruction is not proof of repair; a result is not the underlying observation; a request is not a response.

RFC 5209 says a Result Attribute normally appears at the conclusion of an assessment and indicates whether the endpoint was considered compliant. That restrained verb is operationally important. The result is a product of the evidence the validators received and the policy they applied. It is not a permanent quality welded to the laptop.

Six roles prevent one component from claiming omniscience

The reference model divides the client into Posture Collectors, a Posture Broker Client and Posture Transport Clients. The server side contains Posture Validators, a Posture Broker Server and Posture Transport Servers.

A collector knows about one or more endpoint features. It can gather attributes, respond to a validator, receive results or remediation, and notify the broker when a posture change warrants reassessment. The client broker registers collectors, routes their messages and combines their responses. The transport client carries the dialog over a protected channel.

On the other side, a validator applies policy to attributes for one or more features. It can ask for more information, produce a feature result and issue remediation instructions. The server broker routes among validators and computes a global decision from their individual results and local compliance policy. The transport server maintains the channel.

The architecture is a warning against inference by proximity. A protected transport can prove that a dialog crossed a channel under its security properties; it does not prove that every required collector existed. A broker can faithfully combine the results it received; it cannot observe a disabled component that no collector reported. A validator can correctly apply a rule to an attribute; it cannot make a stale observation current.

The operational receipt should preserve those boundaries. It should say which collectors were expected, which registered, which answered, what each observed and when, which validator consumed the observation, what rule and policy version it applied, and how the global result treated missing or unknown evidence.

Silence is a policy input, not positive posture

This point becomes sharper in RFC 5792, the later PA-TNC specification. Implementations can support different vendor-specific attribute types and must still interoperate. A collector faced with an unsupported request can return an error. Under specified conditions it may return all, some or none of the requested attributes. Several version fields explicitly represent unknown or unavailable values.

That flexibility is necessary for an extensible ecosystem. It also means that coverage must be made visible. Suppose five endpoint features are required but only four have functioning collectors. Four validators can issue positive results. The fifth feature has not thereby passed. It may be unsupported, withheld under privacy policy, unavailable, misconfigured or simply absent from the collector registry.

Local policy is allowed to decide what that means. An organization might deny access, grant a restricted segment, accept a signed prior assertion for a limited period, or permit an exception owned by a named administrator. The mistake is not choosing among those policies. The mistake is recording the absence as evidence that the feature was healthy.

An assessment ledger therefore needs at least three dimensions, not one Boolean: observed result, evidence coverage and policy disposition. pass / 4 of 5 required features / one approved exception until 10:00 is useful. compliant=true erases the very facts needed to reassess it.

Reassessment is the temporal half of the model

RFC 5209 treats reassessment as its second major use after checking posture when an endpoint connects. The reason is unusually plain: network compliance policies and endpoint posture can change. A system initially assessed as compliant can cease to comply after a change. The RFC's examples include the user who disables a host firewall and a policy that begins to require a newly issued firewall patch.

The change can originate on either side. A collector can observe local posture movement and notify the client broker. A validator can observe an out-of-band policy or threat update and notify the server broker. A service request, timer or administrative event can also cause a deployment to reassess.

This makes the current state of the trigger path part of the compliance claim. Did the collector actually subscribe to the relevant change? Was the broker available? Did it persist notifications across restart? Was a reassessment queued, begun and completed? Did the policy-update path reach all validators? A system that records only successful assessments and not failed triggers creates a biased history: green outcomes are durable, while evidence that should invalidate them disappears.

RFC 5209 also describes assertion attributes that can summarize a successful prior assessment and be dated and signed for reuse during a period. This is an optimization, not an escape from time. The assertion needs an issuer, endpoint binding, covered policies and features, issue and expiry times, signature verification and conditions that force a fresh assessment. If its acceptance rule ignores a known posture change, the problem lies in that rule, not in the cryptographic quality of the assertion.

Protected evidence can still be narrow evidence

NEA protocols are designed to protect the assessment dialog and attributes against threats such as modification, replay and theft. These protections matter. A system that cannot distinguish a fresh result from a replayed old result cannot make a credible present claim.

But freshness and truth are not synonyms. A newly transmitted attribute can report only the feature its collector sees. A correctly authenticated endpoint can still run a collector with limited visibility. A protected broker exchange does not prove that the collector's local sensor was healthy. Cryptography secures the statement and its provenance under a trust model; it cannot add missing observation.

The correct evidence chain is explicit:

endpoint/session bound → collectors expected → attributes observed → broker delivered → validators evaluated → global result formed → authorization decided → rule enforced → change monitored → reassessment completed.

Every arrow crosses a control surface. Where the receipt ends, certainty ends. A green result at the validator stage cannot flow automatically into “rule enforced” or “still compliant” without receipts from those later systems.

An assessment result is not an access-control actuator

RFC 5209 says an assessment result may influence an access decision provisioned to enforcement mechanisms. It also says enforcement mechanisms and protocols are out of scope. The communication and representation of NEA results to network-access technology are out of scope too.

That is not a missing feature. It is a clean allocation of authority. NEA evaluates posture. An authorization system decides how that evaluation affects access. An enforcement point installs and retains a rule. Packets and applications reveal the effect.

The distinctions survive in both directions. A compliant result does not prove access was granted, because another authorization condition may fail. A network session that has access does not prove every posture test passed, because local policy may permit restricted access, an exception or a decision based on another mechanism. A remediation message does not prove remediation ran. Only a later observation can show that the endpoint changed as intended.

An audit that wants to claim enforcement must collect the authorization consumer, input result, decision mapping, endpoint/session binding, target enforcement point, rule identifier, installation acknowledgement, activation time and observed effect. Otherwise it should say exactly what it has: an assessment result delivered up to a named boundary.

The receipt that can support a present-tense claim

A useful NEA record begins with assessment ID, session ID, endpoint binding, network attachment and trigger. It lists the expected and responding collectors and validators, their versions and configuration hashes. It preserves each request, returned attribute, observation time, unsupported type, unknown value, omission and processing error.

For every feature result it records validator identity, policy version, input set, rule, outcome and reason. For the global result it records aggregation policy, exceptions and the treatment of unknowns. If a prior assertion was accepted, it records its scope, issuer, validity window and cancellation conditions.

Then the receipt continues beyond NEA only when those systems provide their own evidence: authorization decision, enforcement target, installed rule, remediation execution and remeasurement. Finally it records the last relevant posture change, last policy change, last successful reassessment, failed trigger and current evidence age.

This can sound like more data than a green badge deserves. In practice, most fields already exist somewhere. The discipline is to retain their provenance instead of flattening them. It allows an operator to say: assessment passed at 09:00; firewall changed at 09:17; reassessment trigger failed; current compliance unknown; access rule still active. That sentence gives engineers a place to act.

Preserve the value of the pass by refusing to overstate it

The narrow reading does not weaken endpoint assessment. It rescues it from impossible expectations. RFC 5209 provides a model for moving posture observations to policy validators, combining results and prompting remediation. RFC 5792 and the related PB and PT specifications make portions of that interchange concrete. These are useful coordination mechanisms.

They become brittle only when an assurance layer promotes a historical decision into a permanent endpoint identity. Once compliant loses its timestamp, collector coverage and policy version, the label acquires symbolic power: it can outvote the running machine. A current firewall observation looks like a discrepancy against the database instead of the database looking stale against the firewall.

Running code should win that dispute. The current collector state, pending reassessment, policy epoch and enforcement acknowledgement describe the operational system. The historical pass remains true within its boundary. It should not be deleted; it should be dated.

At 09:00, the laptop passed. At 09:17, a condition changed. At 09:25, the honest result was no longer “failed” or “passed” but “not reassessed after a relevant change”. That is not a weaker security posture. It is the first statement precise enough to improve one.

Sources