Halifax OÜ · Tartu, EstoniaEU patent pendingMMXXVI
Yielded Authority RelayYAR
Verify authority before anything moves.
YAR is cybersecurity infrastructure that verifies, bounds, and records delegated authority before it propagates further — across credentials, permissions, messages, files, API access, and machine instructions.
Existing identity and workflow systems record events. YAR records the authority chain beneath them — creating a structural propagation graph for fraud containment, revocation, and regulatory audit.
Patent pendingCII Method and SystemFiled at the European Patent Office
§ I · The gap
The gap in the chain.
Even when ServiceNow, SailPoint, and Okta did everything they were designed to do — the gap is still there. This is the gap YAR closes. For regulated EU firms under NIS2 and DORA — banking, energy, healthcare, critical infrastructure — this gap is the substance that supervisory examinations will record as non-conformance.
File no. NIS2-A21-CS-001 · Industry Case Study
The Incident Register
Regulated industry · Jurisdiction: EU
Chapter one · Week one
A new joiner. A verbal request. A cascade begins.
Imagine a new joiner at a regulated firm, in their first week. Their manager calls them over: a contractor's credentials have expired and need to be renewed urgently, ahead of a critical go-live. The new joiner returns to their desk and issues the credentials through the central identity platform — the part of the contractor's access they have authority to issue. The contractor also needs access to the deployment pipeline, the secrets vault, and the production database — each governed by a different team with its own authority and its own rules for granting access. The new joiner triggers requests to each; the DevOps lead, the security team, and the DBA team will each authorise within their own domain, each acting on what they understand to be the manager's request, each producing their own record of what they granted.
The next day the contractor calls — they can't complete the work themselves; they need a subset of credentials issued for a specialist coming in for a week to fix something they can't. The new joiner asks the contractor to put the request in an email so it's recorded, then triggers the cascade again across the same domains. Some authorities act quickly; some require additional verification; the specialist's access ends up being granted by a different mix of people than the contractor's was. The original contractor credentials, renewed under the manager's verbal urgency, have no expiry dates across most of the domains.
Chapter two · Six months later
The investigation arrives. The tools did their job.
The new joiner is still at the company. The manager has left. The new joiner is called into a meeting: there has been a breach elsewhere in the firm — not connected to anything they worked on. But the investigation requires the firm to demonstrate the unbroken chain of authority delegation that NIS2 Article 21 requires — that every credential in operation traces back through a legitimate, bounded path from a properly authorised source.
The firm has the mature stack you would expect: ServiceNow for workflow and approval, SailPoint for entitlement governance, Okta for identity. The access logs across multiple systems show credentials generated under multiple users' accounts. ServiceNow records tickets and approval workflows for each individual provisioning event — the new joiner's IAM grant, the DevOps lead's pipeline approval, the security team's vault entitlement, the DBA team's database access. Each event is recorded properly within its domain; each approver acted within their own policy; the tools did exactly what they were designed to do.
But ServiceNow records the events, not the chain of authority that connected them back to the manager's verbal request — the relationship between the parallel domain approvals, the bounded scope each approver was operating within, the structural derivation from the original authorisation. SailPoint can show who currently holds what entitlement; ServiceNow can show how each entitlement was approved; Okta can show the credentials issued — none of them holds the unified chain of bounded delegation that traces back to a single source of authority.
Chapter three · The reckoning
Reconstruction from fragments. The real threat surfaces.
The chain itself lives only in recollection.
They try to piece together what happened. The email confirming the contractor's escalation was deleted three months ago under the firm's 90-day inbox retention policy. There is no record of the original verbal authorisation. The contractor's credentials, with no expiry across most domains, are still active. The audit trail is being assembled from fragments scattered across multiple authority domains that were never designed to be unified. Without a structural record of the cross-domain delegation chain, the firm cannot demonstrate the unbroken chain Article 21 requires; the gap between procedural compliance and provable structural integrity is the gap the supervisory examination will record.
The breach is no longer the threat. The threat is the investigation itself — the documentation sweep, the non-conformance findings, the regulatory exposure, the weeks of reconstruction labour drawing senior people away from operational work. The cost of structurally preventing this audit gap is materially smaller than the cost of resolving it after the fact.
What YAR provides
This is the operational reality YAR was built to address. Not by adding more controls or more logging, but by making the propagation chain itself the structural audit record at the moment authority changes hands.
The chain lives in the propagation graph — an append-only structural record of each derivation event, operating across multiple authority domains regardless of which team, system, or rule-set governs each domain's internal authority. YAR doesn't replace ServiceNow, SailPoint, or Okta — each continues to operate as the system of record for the events within its domain. YAR provides the structural propagation layer underneath, recording the cross-domain chain of bounded delegation that these individual tools each capture only their own piece of.
The propagation graph is content-independent by construction — the chain of authority survives the deletion of associated communications under retention policies, because the structural record holds the chain regardless of which application-layer artefacts remain. The original authorisation, from manager to new joiner to the parallel domain authorities to the contractor and the specialist, would be reconstructible deterministically from any point in the chain, regardless of personnel changes, system migrations, or content erasure.
Under NIS2 and DORA supervisory examination, the propagation graph functions as structural evidence of Article 21 access control and supplier-relationship enforcement — auditable proof that operates independently of application-layer log integrity, content retention, and personnel continuity.
YAR is the patent-filed system and method that provides independently verifiable, server-side structural record of the propagation chain — to back you up when the investigation arrives, even when ServiceNow, SailPoint, and Okta did everything they were designed to do.
§ II · Why this matters
Why this matters.
For most of human history, trust moved person to person — through relationships established before any specific exchange, knowledge passed intimately to those we trusted for the next generations.
The 20th century scaled this differently. Papers, passports, bank books, cheques, credit letters — institutional intermediaries vouched at scale for what strangers could not verify directly. We built the infrastructure to carry that vouching across distances: postal services, telegraph cables, shipping lanes, eventually fibre and satellites. We came to trust the infrastructure itself. This pattern built the global economy of the past century. The 21st century digitised both layers — same pattern, faster and reaching further.
The infrastructure was visible; the chain of operation was inspectable. Digital systems inherited the propagation pattern without inheriting the inspectability.Archive image · Illustrative
But the question worth asking is whether digitisation needs to be only this. We now have technology that could let us establish trust infrastructure deliberately, at high speed, on demand — not just send digital messages in bottles hoping they reach friendly recipients, but build the channel first and share within it. The way humans always did before institutional intermediation became the scaling mechanism.
YAR is the verifiable digital infrastructure that makes this possible. Propagation chains humans can verify, or designate machines to verify on their behalf. Channels established structurally before payload flows. Not a replacement for what served its purpose — an underlying architectural option for the contexts where it matters most.
The pattern we inherited was a scaling mechanism, not the destination. What becomes possible when the verified channel comes first? That is the question YAR is built to answer.
§ III · Where this matters
Three concrete classes of authority propagation.
YAR is not a compliance tool with an architectural backstop. It is a cybersecurity infrastructure layer that addresses three substantively distinct classes of authority propagation risk that current tooling cannot structurally govern.
01
Social engineering and executive impersonation
A message, approval, instruction, or file should not be trusted merely because it appears to come from a known person or system. YAR verifies whether the sender had the authority to propagate that instruction in that context — and contains blast radius if the initial deception succeeds.
02
Partner and supply-chain delegation
When authority crosses vendors, contractors, platforms, or subsidiaries, YAR records the chain of delegation and ensures each step is structurally narrower than the one before it. Cascade revocation traverses the chain when upstream authority is withdrawn.
03
Machine and API authority
As APIs, agents, and automated systems act on behalf of users or organisations, YAR provides a structural record of what authority was delegated, by whom, under what constraints, and whether it can still be trusted at the moment of action.
§ IV · Problem
Authorisation that survives delegation.
In multi-tier delegation chains, who is responsible when something goes wrong — and how much damage can be contained when it does?
YAR addresses three classes of cybersecurity challenge that emerge when access credentials propagate beyond their original cohort. The NIS2 Directive brings an estimated 160,000 entities across the European Union into expanded cybersecurity supply-chain accountability obligations, with parallel requirements emerging under DORA for financial services and the Cyber Resilience Act for connected products.
Fraud and social engineering
Controlled propagation with bounded attenuation prevents compromised credentials from virally spreading authority into unintended hands. Each derivation is structurally narrower than its parent, by architecture rather than by policy.
Social engineering
Supply-chain and partner authority
Multi-tier identity governance with full chain-of-custody traversal, designed for deployments subject to NIS2 and DORA supply-chain accountability requirements. Identity resolution remains within each host system's security boundary.
NIS2 · DORA · Cyber Resilience Act
Insider threat and privilege escalation
Configurable revocation cascade — single node, full subtree, or immediate descendants only — contains blast radius from compromised internal accounts. Cascade traversal remains functional after structural erasure of intermediate node data.
Identity governance · Blast-radius containment
Most organisations today govern these delegation chains through spreadsheets, ticketing systems, and tribal knowledge — a record that is neither structured nor independently verifiable when a regulator, an auditor, or an incident responder asks the difficult questions. YAR turns delegation governance into an independently verifiable, structured, queryable, attestable graph, sitting beside the identity provider and the permission-check engine your stack already has.
§ V · Built for
Where YAR fits.
YAR is the system of record for delegated authority. It does not replace an identity provider or a permission-check engine — it works alongside them, governing the layer those systems leave unaddressed: how authority propagates across multi-tier delegation chains once it has left its origin. Where an identity provider establishes who a principal is, and a permission-check engine answers whether a single request is allowed, YAR maintains the auditable lineage of how a credential came to exist across successive delegations — and enforces that authority only ever narrows along the way. The architecture operates independently of any identity provider or centralised identity store, governing propagation across boundaries that no single vendor controls.
Compliance management platforms, identity governance products, and audit tooling can integrate with YAR as the underlying authorisation-propagation layer rather than rebuilding it themselves. The architecture is designed to be additive to existing regulated-environment infrastructure.
Identity governance teams
At enterprises operating under NIS2 supply-chain accountability and DORA operational resilience obligations. YAR provides chain-of-custody traversal across multi-tier delegation graphs without consolidating identity into a centralised store.
NIS2 · DORA · Identity governance
Platform engineering leaders
Building API delegation, partner-channel access, or marketplace authority models that require blast-radius containment when credentials are compromised. Configurable revocation modes contain damage at architectural scale.
API platforms · Partner channels · Marketplaces
Risk and compliance officers
At financial institutions and regulated industries subject to GDPR Article 17 erasure obligations alongside DORA continuity and forensic-reconstruction requirements. Structural erasure satisfies both without sacrificing audit traversal.
Financial services · Regulated industries
The propagation engine is implemented and undergoing validation in a private development environment. Current pilot engagement is focused on mid-market organisations operating under NIS2 supply-chain accountability obligations, where multi-tier delegation governance is both legally required and inadequately addressed by existing identity infrastructure.
§ VI · Architecture
A propagation graph maintained server-side.
YAR's central artifact is a propagation graph — a topology of derivation relationships recording how authority moves across delegation chains. The graph supports decision-making about further propagation in real time, structural enforcement of constraints at the point of generation, and forensic traversal that survives erasure of associated content. The architecture comprises five primary mechanisms that maintain this graph.
Credential Delegation Chain
Simulation · Propagation lifecycle walkthrough
YAR engine logic · simulated replay
policy · max depth: 5 · max issuance: 10 · revocation: cascade · allowance: reallocate on expiry
Server-side derivation relationships.Each credential records its parent reference and tier value as structural data, separated architecturally from associated application content.
Constraint verification at generation.Before issuing any child credential, the engine evaluates structural depth, propagation allowance, and configurable preconditions against the parent's current propagation state.
Bounded attenuation.Derived credentials cannot exceed their parent in any constrained dimension — depth, breadth, scope, permitted operations, or validity period.
Structural erasure preserving topology.Associated application data may be nulled on request while structural fields are retained, preserving graph topology, constraint state, and deterministic traversal independently of whether associated data is present.
Configurable revocation cascade.Three policy modes — single credential, full subtree, or immediate descendants only — applied at compromise response. Cascade traversal operates on retained structural data and remains functional after erasure of intermediate nodes.
A real-time graph is YAR's primary output. The propagation graph operates independently of the application overlay where sensitive data lives — it sees structure and policy, never content. This separation lets the graph be audited for compliance without exposing underlying data, and lets associated content be erased while structural relationships remain intact. Authorisation governance is the first application domain — the most immediately commercial and the focus of current deployment. The same architecture supports adjacent decision-making problems wherever authority, influence, or responsibility propagates across multi-tier chains: supply-chain attribution, partner-tier audit, propagation forensics, and incident reconstruction across regulated environments.
§ VII · Regulatory alignment
Designed for regulated deployment.
YAR's architecture is designed for deployments subject to oversight and accountability requirements across European cybersecurity and digital operations regulation. The propagation engine provides structural enforcement of authorisation controls that ISO 27001 frameworks typically address through procedural means.
The credential generation engine supports configurable oversight checkpoints through digitally signed operator attestations, anomaly-driven propagation throttling, and forensic reconstruction across delegation chains independently of retained associated application data. The propagation graph itself functions as a structural audit record — every credential generation, derivation, and revocation event captured immutably, deterministically resolvable from any descendant back to origin, and survivable under conditions that compromise application-layer logging. The result is auditable compliance posture for Annex A.9 (Access Control), A.12.4 (Logging and Monitoring), and A.15 (Supplier Relationships) under the regulatory pull of NIS2 and DORA implementation cycles.
Halifax OÜ is in active development of YAR's propagation governance engine. Six contexts illustrate where the architectural approach maps to operational authority management challenges in regulated environments:
Contractor onboarding with bounded propagation across multiple authority domains
Supplier access delegation with cascade revocation under contract changes
Executive approval workflows with structural attribution to originating authority
Privileged access requests with bounded attenuation enforced at credential generation
Machine-to-machine API authorisation with structural propagation governance
Regulated file or instruction forwarding with chain-of-custody audit trail
Substantive engagement involves mapping a partner's authority propagation flow, identifying the structural gaps current tooling cannot address, and producing a specification for how propagation governance would resolve them. Implementation work follows specification work; pre-commercial collaboration produces both.
Substantive conversations with regulated organisations and infrastructure partners — as well as compliance management platforms, identity governance providers, and audit-tooling vendors exploring authorisation propagation as a foundational layer — are equally welcome.
