KYD® Specification v1.0

The Device Trust Standard — Public Specification

The KYD® Specification defines the minimum requirements for establishing and maintaining device trust.

It formalises what it means for a device to be trusted — continuously, not once — and provides a shared framework that can be implemented across systems, environments, and industries.

Purpose of the Specification

The KYD® Specification exists to:

define the core concepts of device trust
establish consistent terminology
specify minimum requirements for compatibility
enable independent implementation
support reference, audit, and adoption

It is designed to be read by:

system architects
platform and infrastructure builders
hardware manufacturers
auditors and insurers
standards and governance bodies

What the Specification Covers

KYD® Specification v1.0 defines requirements relating to:

Device Identity

Persistent identification that remains stable across time, networks, and operating conditions.

Baseline Formation

How expected device behaviour is established through observation and evidence.

Device Drift

How deviation from expected behaviour is identified, recorded, and evaluated.

Trust Evaluation

How trust states and trust scores are derived from accumulated evidence.

Proof Over Time

How historical trust decisions remain explainable, inspectable, and auditable.

The specification defines what must be true, not how it must be engineered.

Scope and Non-Goals

The KYD® Specification does not:

mandate a specific architecture
require specific hardware
prescribe enforcement actions
guarantee security outcomes

KYD® defines trust evaluation, not threat prevention.

Implementations may vary, provided they conform to the requirements of the specification.

Versioning and Stability

This is KYD® Specification v1.0.

The specification is versioned
Compatibility references a specific version
Future versions will extend, not invalidate, prior definitions

Implementers are expected to reference the version they support.

Governance

KYD® is a registered trademark.

The specification is:

maintained to ensure consistency
governed to preserve meaning
designed for long-term stability

Changes to the specification are deliberate, versioned, and documented.

Relationship to Implementations

The KYD® Specification defines the standard.

Implementations demonstrate how the standard can be applied in practice.

Know Your Devices™ is the reference implementation of the KYD® standard, but the specification is not dependent on any single implementation.

Other implementations may exist, provided they conform to the specification.

How the Specification Is Used

The KYD® Specification may be referenced in:

technical documentation
procurement requirements
audit and assurance processes
insurance and underwriting discussions
policy and governance frameworks

It is intended to function as infrastructure language, not marketing material.

3. Definitions

The following terms are defined normatively within this specification:

3.1 Device

A physical or virtual entity capable of network connectivity, data generation, observation, or action within a system.

3.2 Device Identity

A persistent, recoverable identifier that remains stable across network changes, reboots, firmware updates, and configuration modifications.

3.3 Device Trust

A continuously evaluated state reflecting the degree to which a device’s observed behavior aligns with expected behavior, derived from accumulated evidence over time.

3.4 Baseline

A representation of expected device behavior established through observation and evidence collection during a learning period.

3.5 Device Drift

Observable deviation from baseline behavior, including changes to identity characteristics, communication patterns, or operational state.

3.6 Trust State

A categorical representation of device trust (e.g., Learning, Trusted, Requires Attention, At Risk) derived from trust evaluation.

3.7 Trust Score

A numerical representation of device trust, typically expressed on a normalized scale, derived from multiple trust factors.

3.8 Proof Over Time

Historical records of trust evaluations, decisions, and supporting evidence that remain explainable, inspectable, and auditable.

3.9 Trust Evaluation

The process of deriving trust states or trust scores from observed device behavior, identity continuity, drift events, and accumulated evidence.

3.10 KYD-Compatible

A system that conforms to the requirements of this specification.

4. Requirements

This section defines normative requirements for KYD-compatible systems.

4.1 Device Identity Requirements

4.1.1 Persistence

A KYD-compatible system MUST maintain device identity across:

network address changes (DHCP reassignment, subnet changes)
device reboots and power cycles
firmware or software updates
configuration changes that do not alter fundamental device characteristics

4.1.2 Uniqueness

Device identities MUST be distinguishable from one another within the scope of the implementation.

4.1.3 Stability

Device identity MUST be derived from characteristics that are sufficiently stable to enable tracking over time.

4.1.4 Recoverability

If a device identity is lost or corrupted, the system SHOULD provide mechanisms to recover or re-establish identity based on observable characteristics.

4.1.5 Identity Change Detection

A KYD-compatible system MUST detect when a device’s identifying characteristics change in ways that affect identity continuity.

4.2 Baseline Formation Requirements

4.2.1 Observation Period

A KYD-compatible system MUST observe device behavior over time before establishing a baseline.

The observation period SHOULD be sufficient to capture normal operational patterns.

4.2.2 Evidence-Based Formation

Baselines MUST be formed from observed evidence, not assumed behavior.

4.2.3 Baseline Characteristics

A baseline MUST include at least:

device identity characteristics
communication patterns (protocols, ports, destinations)
temporal behavior (connection times, frequency)

4.2.4 Baseline Updates

The system SHOULD support baseline refinement as additional evidence is collected, without discarding historical context.

4.2.5 Multiple Baselines

The system MAY maintain multiple baselines for devices with varying operational modes or contexts.

4.3 Device Drift Requirements

4.3.1 Drift Detection

A KYD-compatible system MUST detect deviations from established baselines.

4.3.2 Drift Classification

The system SHOULD classify drift by type, including but not limited to:

identity drift (changes to identifying characteristics)
behavioral drift (changes to communication or operational patterns)
temporal drift (changes to connection timing or presence patterns)

4.3.3 Drift Recording

All detected drift events MUST be recorded with:

timestamp of detection
type of drift observed
characteristics that changed
magnitude or significance of change

4.3.4 Drift Evaluation

The system MUST evaluate whether drift impacts device trust.

Drift evaluation SHOULD consider:

frequency of change
magnitude of change
context of change (e.g., time of day, network conditions)
historical patterns

4.3.5 Benign Drift

The system SHOULD distinguish between expected drift (e.g., firmware updates, authorized configuration changes) and unexpected drift.

4.4 Trust Evaluation Requirements

4.4.1 Continuous Evaluation

Trust evaluation MUST occur continuously, not only at initial connection.

4.4.2 Multi-Factor Evaluation

Trust evaluation MUST incorporate multiple factors, including at least:

device identity continuity
behavioral consistency with baseline
observed drift events
temporal patterns (presence, absence, regularity)

4.4.3 Trust State or Trust Score

A KYD-compatible system MUST produce either:

categorical trust states (e.g., Learning, Trusted, Requires Attention, At Risk), OR
numerical trust scores on a defined scale, OR
both

4.4.4 Explainability

Trust evaluations MUST be explainable.

The system MUST be capable of presenting:

which factors contributed to the trust evaluation
why the current trust state or score was assigned
what evidence supports the evaluation

4.4.5 Trust State Transitions

The system MUST record when and why trust states change.

4.4.6 Degradation

Trust SHOULD degrade in the absence of positive evidence or in the presence of unexplained drift.

4.5 Proof Retention Requirements

4.5.1 Historical Record

A KYD-compatible system MUST retain historical records of:

trust evaluations over time
drift events
identity changes
baseline formation and updates

4.5.2 Minimum Retention Period

Historical records MUST be retained for a minimum of 90 days.

Implementations MAY retain records for longer periods.

4.5.3 Auditability

Historical records MUST be retrievable for audit purposes.

4.5.4 Tamper Evidence

The system SHOULD provide mechanisms to detect tampering with historical records.

Implementations MAY use cryptographic techniques (e.g., signing, hashing) to ensure integrity.

4.5.5 Proof Format

Historical records SHOULD be exportable in a structured format suitable for audit and compliance purposes.

4.5.6 Time Accuracy

All timestamps in historical records MUST be accurate and SHOULD be synchronized to a reliable time source.

5. Conformance Criteria

5.1 Self-Assessment

An implementation may claim KYD-compatibility through self-assessment against this specification.

5.2 Required Conformance

To claim KYD-compatibility, an implementation MUST:

Satisfy all normative requirements marked “MUST” or “REQUIRED”
Document how each requirement is satisfied
Provide evidence of conformance for critical requirements (4.1, 4.3.1, 4.4.1, 4.5.1)
Not contradict or redefine terms established in Section 3

5.3 Partial Conformance

Implementations that satisfy some but not all requirements MUST NOT claim full KYD-compatibility.

Partial conformance MAY be stated explicitly (e.g., “Implements KYD® device identity requirements”) provided specific sections are referenced.

5.4 Conformance Testing

The system SHOULD be testable for conformance using:

observation of identity persistence across network changes
verification of baseline formation from evidence
detection of introduced drift
retrieval of historical trust records

5.5 Documentation Requirements

KYD-compatible implementations SHOULD provide documentation describing:

how device identity is established and maintained
baseline formation methodology
drift detection mechanisms
trust evaluation algorithms or approaches
proof retention capabilities

6. Relationship to Existing Standards

6.1 Complementary Standards

KYD® is designed to complement, not replace, existing standards:

ISO/IEC 27001 (Information Security Management)

KYD® provides device-level trust evaluation that supports asset management and access control requirements.

NIST Cybersecurity Framework

KYD® contributes to the “Identify” and “Detect” functions by providing continuous device visibility and behavioral monitoring.

IEC 62443 (Industrial Automation and Control Systems Security)

KYD® can be applied to evaluate trust in industrial devices and SCADA systems.

IEEE 802.1X (Network Access Control)

KYD® extends authentication-based access control with continuous trust evaluation.

Zero Trust Architecture (NIST SP 800-207)

KYD® implements continuous verification principles at the device level.

6.2 Standards Integration

KYD-compatible systems MAY integrate with or reference other standards provided they:

do not contradict KYD® definitions
clearly distinguish which requirements derive from KYD® vs. other standards
maintain KYD® conformance independently

6.3 Standard Evolution

As related standards evolve, KYD® compatibility does not require adoption of changes unless explicitly incorporated through the KYD® governance process.

7. Normative References

RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels
KYD® Governance & Versioning Policy v1.0 - Defines how this specification evolves
KYD® Compatibility & Usage Guidelines v1.0 - Defines proper reference and usage

8. Download PDF

KYD® Specification v1.0 (PDF)

Foundational definition of the KYD® Device Trust Standard.

Download PDF (Coming soon)

Legal Notice

KYD® is a registered trademark in the United Kingdom (UK00004274651).

United States registration pending (Serial 99480838).

Use of the KYD® name or references to compatibility must align with the published specification and trademark guidance.

KYD® — The Device Trust Standard

Proof, not assumptions.