usnistgov

My Mac Advertises Five Services, All Five Carry My Name On 21 October I counted the listening sockets on this machine: 42 of 55 were unreachable from the network. A comforting ratio. But that measurement answers exactly one question: *what happens if someone tries to connect?* This week I realised the real event is over before that. Nobody has to try anything — the machine has already told the network who it is. And what it tells isn't a port number. It's my name. Every measurement here was taken on the morning of 8 November 2026, on a single machine: macOS 26.6.2 (build 25G83), Apple M4 Pro, hw.model = Mac16,7, no MDM enrolment (profiles status → "MDM enrollment: No", and no configuration profile installed for the user either). The network I'm on is WPA2 Personal and the machine's address is 192.168.1.20. Every command is read-only; I didn't change a single setting for this piece. Near the end I list what I couldn't measure, because on this topic that list isn't short. One scan, seventeen rows On macOS the way to ask what services are on the network is dns-sd. I asked which service types are being advertised: $ dns-sd -B _services._dns-sd._udp local. Timestamp A/R Flags if Domain Service Type Instance Name 8:40:28.302 Add 3 1 . _tcp.local. _rfb 8:40:28.302 Add 3 1 . _tcp.local. _airplay 8:40:28.302 Add 3 1 . _tcp.local. _raop 8:40:28.302 Add 3 1 . _udp.local. _net-assistant 8:40:28.302 Add 3 1 . _tcp.local. _companion-link ... Seventeen Add rows, twelve distinct service types. The curious thing about this command is that the part you're looking for sits at the end of the line: the "Service Type" column says _tcp.local., while the service's actual name lands under "Instance Name". You read it backwards the first time. The if field is the interface index. Five types appear twice — once on index 1, once on index 14; the remaining seven appear only on 14. That is where the seventeen rows come from: five types twice, seven types once. Index 14 is this machine's Wi-Fi interface; the other devices at home come in through it, and they're not the subject of this piece. I have no intention of publishing an inventory of my own household. The five types I care about are _rfb, _airplay, _raop, _net-assistant and _companion-link. I did not infer that these belong to this machine from the interface index alone — I browsed each one separately. Every time, the single instance that came back carried this machine's ComputerName, with its SRV target pointing at its LocalHostName: $ for t in _rfb._tcp _airplay._tcp _net-assistant._udp \ _companion-link._tcp _raop._tcp; do dns-sd -B $t local.; done _rfb._tcp. mustafa MacBook Pro _airplay._tcp. mustafa MacBook Pro _net-assistant._udp. mustafa MacBook Pro _companion-link._tcp. mustafa MacBook Pro _raop._tcp. C642A97923A7@mustafa MacBook Pro All five carry my computer's name. Four of them plainly, and _raop with an identifier bolted on the front. The name itself comes from two separate settings, both readable from the machine's own records: $ scutil --get ComputerName mustafa MacBook Pro $ scutil --get LocalHostName mustafa-MacBook-Pro What the five services are The type names don't explain themselves, so I resolved each one. dns-sd -L tells you which host and port the service lives on: $ dns-sd -L "mustafa MacBook Pro" _rfb._tcp local. ... can be reached at mustafa-MacBook-Pro.local.:5900 (interface 14) $ dns-sd -L "mustafa MacBook Pro" _net-assistant._udp local. ... can be reached at mustafa-MacBook-Pro.local.:3283 (interface 14) I looked the port numbers up in Apple's own list. Apple's document on TCP and UDP ports used by its software (published 28 July 2026) lists 5900 under the service name rfb, used by "Apple Remote Desktop, Screen Sharing". 3283 is net-assistant: Apple Remote Desktop. 7000 is AirPlay, and 5353 is mDNS itself — "Bonjour, AirPlay, Home Sharing, Printer Discovery". So two of the five advertisements are remote access. And they aren't merely advertised; they're genuinely open: $ launchctl print-disabled system | grep -E "screensharing|smbd|ftpd" "com.apple.screensharing" => enabled "com.apple.ftpd" => disabled "com.apple.smbd" => disabled $ lsof -nP -iTCP -sTCP:LISTEN | grep -E "ARDAgent|ControlCe|rapportd" ARDAgent 709 mustafaerbay 9u IPv6 ... TCP *:3283 (LISTEN) ControlCe 716 mustafaerbay 9u IPv4 ... TCP *:7000 (LISTEN) ControlCe 716 mustafaerbay 10u IPv6 ... TCP *:7000 (LISTEN) rapportd 665 mustafaerbay 5u IPv4 ... TCP *:51786 (LISTEN) File sharing and FTP are off. Screen sharing is on, and the remote management agent is running and listening on *:3283, meaning every interface. The AirPlay receiver does the same: the ControlCenter process holds *:7000 on both IPv4 and IPv6 — a detail that matters again shortly. _companion-link is the Continuity side, rapportd. Let me be honest with myself here: I would love to write "I never turned these on", but I have no record showing that I didn't. The measurement says only this: they are on, and because they are on, they go out onto the network with my name attached. This isn't a leak, it's what the spec asks for My first reaction was "a setting must have slipped past me". It didn't. Reading the service discovery spec, I learned that the readability of that name is not an accident but an explicit requirement. RFC 6763, which defines DNS-SD, splits a service name into three parts: <Instance>.<Service>.<Domain> (section 4.1, "Service Instance Name"). For the Instance part, section 4.1.1 is unambiguous — the name should be "a user-friendly name consisting of arbitrary Net-Unicode text" and "should be a user-visible, user-friendly name rather than an invisible machine-generated opaque identifier". A machine-generated opaque identifier is explicitly not wanted; a name a human can read and recognise is. The appendix it points you to for the reasoning is called "What You See Is What You Get". The logic holds, too. When you open the AirDrop panel you pick devices by their names; seeing a8a5a8… there would be useless. The spec thought about the user. It just didn't think about the stranger at the next table. A few lines further down, the same section pushes the other way: the default name should be short and descriptive, and "SHOULD NOT include the device's Media Access Control (MAC) address, serial number, or any similar incomprehensible hexadecimal string in an attempt to make the name globally unique". My _raop record is named C642A97923A7@mustafa MacBook Pro. Both recommendations apply to all five services at once: five out of five satisfy the first, and four out of five satisfy the second. The extra information attached to a service lives in the same document, section 6: every DNS-SD service must carry a TXT record alongside its SRV record ("Every DNS-SD service MUST have a TXT record"), and per section 6.3 its purpose is "to convey a small amount of useful additional information about a service". Small and useful. Let's look. What's inside the TXT record Here is the AirPlay service's TXT record — shortened, with identifiers masked: act=2 acl=0 deviceid=C6:42:A9:… features=0x4A7FCFD5,0x38174FDE flags=0x204 gid=408CCEE0-… model=Mac16,7 at=4 protovers=1.1 model=Mac16,7. That is character-for-character what sysctl -n hw.model returns on this machine. So the network learns not only my name but which Mac model I use — a string that narrows down the purchase year without anyone having to look up an OS version. The deviceid field is formatted like a MAC address, and my first thought was "there's the stable hardware identifier". Wrong thought. I looked at its first octet: 0xC6 = 1100 0110 └─ Local bit (0x02) = 1 RFC 7042 section 2.1 defines that bit: "The Local bit is zero for globally unique EUI-48 identifiers" — so if the bit is 1, the address is not a globally assigned hardware identifier but a locally administered value. I have to stop here, because my first draft went further than it should have. Apple's Wi-Fi privacy document says Apple "generates randomized MAC addresses for the peer-to-peer Wi-Fi connections that are used for AirDrop and AirPlay" — and that sentence is about the address of the peer-to-peer interface itself, not about the deviceid field inside an mDNS TXT record. It was easy to read the document as backing my claim; I read it somewhere it wasn't looking. All the measurement really says is that this value didn't come from the factory. Whether it is random, whether it changes at every boot, or whether it is pinned to this machine — one observation cannot tell you, and I won't pretend otherwise. The companion-link TXT record carries fields like rpBA, rpAD, rpHN and rpVr. I couldn't find what they mean in Apple's documentation, and I'm not going to invent a meaning for something I couldn't find, so I stop there too. What's left is still an asymmetry, and it is the whole point of this piece: the numbers are opaque, the words are not. Nobody looking from outside can work out what deviceid or rpAD says; for "mustafa MacBook Pro" and Mac16,7 they don't have to. The privacy effort went into the hexadecimal fields, and the plain text was left as it is. Without anyone asking One more thing I wondered: does this announcement go out when someone asks, or on its own? RFC 6762, which defines mDNS, answers in section 8.3. The responder "MUST send an unsolicited Multicast DNS response" — unsolicited. And further: "MUST send at least two unsolicited responses, one second apart". At least twice, a second apart. These go to UDP port 5353 per section 2, and to the multicast address 224.0.0.251 per section 3 — that is, to everyone on the link. The same section also sets the scope of that response, and this is where my first arithmetic fell apart: the response carries all of the machine's newly registered records in its Answer Section ("all of its newly registered resource records"), split across several packets if they don't fit. The announcement is per event, not per service. All five of my services travel in the same packet. When those steps run is written down too. Section 8 says the responder starts over when it "starts up, wakes up from sleep", or when the link changes. Waking from sleep is a trigger. And here an older measurement of mine comes into play. At the end of September I counted this laptop's wake records: 76 full wakes in seven days, and I was at the keyboard for 13 of them. Combine that with the spec and a lower bound appears: 76 wakes × at least 2 responses = at least 152 unsolicited responses that week. The ceiling is written down as well — the same section allows up to eight ("MAY send up to eight"), provided the interval at least doubles each time, which puts the far end at 608. That is the count for one address family. Per section 20, a dual-stack machine takes part in two separate ".local." zones and should register its names over both IPv4 and IPv6 — and we saw above that the AirPlay receiver listens on both stacks. Two zones double the lower bound again. All of that I derived; I did not measure it — capturing packets needs root, and this session has no sudo password. The figure also belongs to that week; this week's wake count will differ. The reassuring half of the spec deserves a line too, because there is one: section 8.3 says a responder "MUST NOT send regular periodic announcements as a matter of course". The machine isn't chattering away; it speaks only when something changes. Noise was never the problem — saying the same two words every time is. !Diagram The ordering in that diagram is my claim: the firewall sits furthest right, because it only rules on an actual connection attempt. The announcement is to its left, and independent of it. What hiding the MAC address actually solves The defence that comes to mind here is Apple's private Wi-Fi address. Per the documentation, macOS Sequoia 15 and later offer three options: Off, Fixed, Rotating. Off is spelled out — "When set to Off, your device uses its hardware MAC address". Fixed is a private address that stays constant per network; Rotating changes every two weeks. The default depends on the network's security: joining a new WPA2-or-stronger network the device chooses Fixed, and on a weak or open network it chooses Rotating. I ran the same bit test on this machine's Wi-Fi address: $ ifconfig en0 | grep ether ether 84:2f:57:… 0x84 = 1000 0100 └─ Local bit (0x02) = 0 The Local bit is 0. By RFC 7042's definition that makes it a globally unique identifier: the manufacturer-assigned address. From there it follows that the private address is off on this network — but I have to say that this is an inference, not a measurement. Apple nowhere documents that its private address sets the Local bit; I reasoned from the standard's logic. The setting itself lives in /Library/Preferences/com.apple.wifi.known-networks.plist, which is -rw------- root wheel; I couldn't open it. And in fairness, evidence against that inference is sitting two paragraphs above, written by me: Apple's documented default on a WPA2 network is Fixed. So the document says it should be on while the measurement says off. At least two explanations survive, and I can rule out neither — either Apple's private addresses don't set the Local bit, or ifconfig prints the hardware address regardless of which address the machine associates with. I couldn't read which on this machine. I won't tell you flatly that it's off; all I know is that the two sources don't meet. But the inference isn't needed for the part that matters: what would change if Rotating were on? The address would turn over every two weeks. The "mustafa MacBook Pro" and Mac16,7 inside the announcement would stay exactly the same. Hiding your identity at the link layer and handing it back as plain text one layer up is like drawing the curtains and then shouting your name out of the window. I also counted how many networks this machine remembers: $ networksetup -listpreferredwirelessnetworks en0 | tail -n +2 | wc -l 18 Eighteen networks. Alongside home and work, the list includes a shopping centre's guest network. Walking into a remembered network connects automatically, and per RFC 6762 section 8 the announcement goes out automatically too. So this identity travels to as many as eighteen different places, saying the same two words at each one. The section the spec doesn't have This is where I was most surprised. Section 21 of RFC 6762 is titled "Security Considerations". I opened it: it is entirely about trust and impersonation. It warns that a responder may be "some local host that is merely masquerading as that name", notes that a client cannot be sure about hostile hosts on the link, and offers IPsec signatures and DNSSEC as remedies. So the spec takes seriously the risk of you being deceived. It never treats what you say about yourself as a disclosure problem. The threat model points one way: from the network toward you. Expecting more from a 2013 document may be unfair. What's interesting is that the gap has been closed in audit standards. NIST's macOS security compliance project has a rule called os_bonjour_disable — the rule file is on GitHub, titled "Disable Bonjour Multicast", with its rationale in one sentence: Bonjour multicast advertising must be disabled so the system doesn't broadcast its presence and services on network interfaces. The rule sets the NoMulticastAdvertisements key to true in the com.apple.mDNSResponder domain; its tags include all three 800-53r5 levels, 800-171, CIS v8 and CMMC level 2, and it is defined for macOS 27.0, 26.0 and 15.0. One detail I shouldn't skip: on the CIS side this is item 4.1 at level 2 — outside the level 1 baseline most organisations are actually audited against — and on the DISA STIG side its severity is "medium". On this machine that domain doesn't exist at all: $ defaults read /Library/Preferences/com.apple.mDNSResponder Domain /Library/Preferences/com.apple.mDNSResponder does not exist No domain means no key, which means the advertisements are on. An audit that checks this control would fail this machine — though, being a level 2 item, not every audit checks it. I'm failing it right now too. What to do — and what not to Applying that rule blindly at home doesn't feel right to me. Turning advertisements off entirely also kills AirDrop, printer discovery, AirPlay and Continuity — three of the five announcements counted here (the two AirPlay records and _companion-link) are those features. The standard was written for managed fleets, not for my kitchen table. The order that makes sense to me is this: 1. Treat the two remote-access services separately. Screen sharing and remote management are the two most expensive of the five advertisements. They're the ones to switch off the moment I don't need them — far less painful than giving up AirDrop. 2. Read the name once — both of them. Whatever scutil --get ComputerName returns, everyone on the network sees it. Checking whether your first name, surname or employer is in there is worth one look. There's a trap here: the name lives in two separate settings, and mDNS uses LocalHostName in the SRV record. Set both, or one of them stays behind: sudo scutil --set ComputerName "work-laptop" sudo scutil --set LocalHostName "work-laptop" 3. Accept the model line. model=Mac16,7 can't be switched off; it's part of the service advertisement. There's no negotiating here, only awareness. 4. Remove untrusted networks from the list. Keeping a guest network on the list means the connection, and the announcement, repeat automatically on every visit. How many of those eighteen are genuinely needed? networksetup -removepreferredwirelessnetwork en0 "<ssid>" 5. Don't treat the private address as the whole answer. It does its job, but at a different layer. Hiding the address doesn't hide the name. One more thing: these three facts look harmless one at a time and change when you set them side by side. The name lets a stranger address you by it. Mac16,7 says which hardware you're on. The third is that the same identity repeats on every remembered network — a trail showing that this machine went there. All three came out of the commands above, written down separately; not drawing the line between them would have been a cop-out. What I couldn't measure The honesty section. I couldn't capture packets to confirm the announcements actually go out; listening to 5353 traffic needs root. I couldn't read the security types of remembered networks, or each network's private-address setting, for the same reason. I also didn't test whether 5900 and 3283 are reachable from the network — connecting to my own address from my own machine isn't a real network path, so the result of the socket count of 21 October still stands here — and that piece says itself that the 42 was derived rather than measured: being advertised is not the same as being reachable. But reachability isn't this piece's claim. The announcement goes out even when the access question is never asked. What stays with me We always frame the privacy conversation around connections: which port is open, what the firewall says, who can connect. On this machine the answer to that question is reasonable. Yet identity leaves ahead of any connection and independently of it — and it does so because the spec asks for it, not because something broke. Discovery protocols were designed to introduce us to each other, and they do their job very well. There's no reason for them to stop introducing us; the real question is that we never read what they say while doing it. Until I read section 4.1.1 of a nearly fourteen-year-old specification, it hadn't occurred to me that the name I gave my computer had become the payload of a network protocol. The next time you join a network, your machine will speak on your behalf. At least walk in knowing what it says. Official Sources - RFC 6763 — DNS-Based Service Discovery - RFC 6762 — Multicast DNS - RFC 7042 — IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters - Apple — TCP and UDP ports used by Apple software products - Apple — Use private Wi-Fi addresses on Apple devices - NIST macOS Security Compliance Project — os_bonjour_disable

テストが緑でも、条件を一つ変えれば結果が変わる。 「PASSした」と「正しい」は別物。 fipy#1225

@lewang_teraliq We just posted this to NIST to make sure AI measurements join the rest of the sciences with metrology ai-metrology-submissions#28

Why Use NIST OSCAL? Compliance as Data, Not Documents TL;DR What it is. OSCAL, the Open Security Controls Assessment Language, is an open standard from NIST. It expresses security controls, system security plans, assessments, and remediation plans as structured data in XML, JSON, or YAML. It is free, open source, and developed in the open on GitHub. The latest release at time of writing is v1.2.3. Why use it. Most compliance work still lives in Word documents and spreadsheets that are out of date the day they are signed. OSCAL turns that paperwork into data that tools can validate, compare, and update. Write a control implementation once and reuse it across frameworks. Hand assessors evidence they can process by machine. Move from an annual snapshot toward continuous assurance. Why now. Regulators are publishing controls as data. US federal cloud authorization is moving toward machine-readable packages, Canada's control catalogues descend from the NIST controls OSCAL was built around, and Germany now publishes its national baseline natively in OSCAL. Meanwhile the number of frameworks you answer to only grows. The problem OSCAL solves Ask a security team how many frameworks it reports against. SOC 2, ISO 27001, NIST SP 800-53, CIS, provincial privacy law, customer questionnaires, and now AI-specific frameworks. Each one gets its own document, its own spreadsheet, and its own late-night copy-and-paste session before the audit. The underlying facts barely change between them. Multi-factor authentication is enforced the same way whether ISO or SOC 2 asks about it. Yet the same answer is rewritten for each framework, in prose no tool can check, by people who would rather be fixing things. That model has three failures: 1. Drift. The document says one thing, the system does another, and nobody notices until an assessor or an attacker does. 2. Duplication. Every new framework multiplies the work instead of reusing what is already known. 3. Opacity. A 300-page PDF cannot be queried. "Which controls depend on this identity provider?" takes a week to answer. What OSCAL actually is NIST describes OSCAL as a set of formats that give a standardized, machine-readable representation of control information, from catalogs to assessment results. The models fall into three layers: - Control layer. Catalogs hold the control definitions, such as NIST SP 800-53. Profiles select and tailor controls into a baseline, such as Moderate or your own internal standard. - Implementation layer. Component definitions describe how a product or service satisfies controls. A system security plan (SSP) describes how a specific system implements its baseline. - Assessment layer. Assessment plans, assessment results, and plans of action and milestones (POA&M) record what was tested, what was found, and what is being fixed.  Each layer references the one above it. An SSP points to a profile, which points to a catalog. An assessment result points to the SSP. That chain of references is the point: change a control, and you can trace every system and finding it touches. Why organizations should use it Write once, map many times Describe how your platform enforces encryption at rest as a component definition. Reference it from every system that uses the platform. When a framework or a customer asks, the answer comes from the same source, not a fresh rewrite.  Documentation that can be checked OSCAL content validates against published schemas. A missing control, a broken reference, or a parameter left blank is caught by a tool, not by an assessor three weeks before your deadline. That changes compliance from a writing exercise into something closer to software, with versions, reviews, and automated checks. Vendor and supplier assurance at scale If your cloud and SaaS providers publish component definitions, you inherit their control descriptions as data instead of re-reading their PDFs. The same applies in reverse: if you sell to regulated buyers, a clean OSCAL package shortens their review of you. Continuous assurance instead of annual theatre Once controls, systems, and findings are linked as data, evidence from your pipelines and cloud configuration can feed assessment results directly. Status becomes a query, not a project. This is where OSCAL meets the rest of a modern secure software development lifecycle: compliance becomes another artifact the pipeline produces and checks.  Exceptions become data, too Every program has controls it cannot meet as written: a legacy system that cannot take multi-factor authentication, a scanner finding that turns out to be a false positive, a risk the business decides to accept. In most organizations these exceptions live in email threads and a spreadsheet tab. They rarely have an expiry date, the approver has often moved on, and nobody looks at them again until an assessor asks. OSCAL records exceptions inside the risk record, not beside it. A risk in a POA&M moves through statuses such as open, remediating, deviation-requested, deviation-approved, and closed. Its response is typed as avoid, mitigate, transfer, share, or accept. Properties flag a risk as a false positive, accepted, or risk-adjusted, and a risk log records each status change, who logged it, and when. Because the risk references the finding, the control, and the system, an exception never drifts away from what it excuses. The payoff is the same as everywhere else in OSCAL: questions become queries. Which accepted risks reach their deadline this quarter? Which systems carry exceptions against the same control? Who approved this deviation, and on what evidence? Give every exception a deadline and the pipeline can flag it for review before it quietly becomes permanent. Regulatory direction of travel Machine-readable assurance is no longer a US-only idea. Where you sit changes the details, not the direction. United States. FedRAMP's RFC-0024 proposes that Rev5 cloud providers submit authorization packages in an approved machine-readable format, with OSCAL named as one, starting with new submissions on September 30, 2026. Check FedRAMP's final rules for the scope and dates that apply to you. NIST also publishes its own catalogs, including SP 800-53 and SP 800-171, as OSCAL content. Canada. The federal control catalogue, ITSG-33, is based on NIST SP 800-53, so it maps naturally onto OSCAL's catalog and profile model. The Canadian Centre for Cyber Security has not published an official OSCAL edition, but AWS has encoded the CCCS Medium and Protected B High Value Assets cloud profiles in OSCAL as open samples. For defence suppliers, the Canadian Program for Cyber Security Certification (CPCSC) rests on a standard technically identical to NIST SP 800-171, which NIST already publishes in OSCAL. Level 1 self-assessments enter select defence contracts from summer 2026, and Level 2 third-party certification from spring 2027. Quebec. Nothing in Quebec requires OSCAL today. But Quebec organizations already carry structured obligations that live badly in documents: public bodies answer to the government's information security directive and framework, and Law 25 requires, among other things, privacy impact assessments for certain projects and a register of confidentiality incidents. OSCAL lets you model those obligations as your own catalog, alongside ISO 27001 or ITSG-33, and answer each from the same evidence. Europe. NIS2 and DORA do not prescribe a data format, and the EU has not published official OSCAL catalogs for them. Germany has moved first: the BSI now publishes its security requirements, including Grundschutz++, the successor to IT-Grundschutz, as OSCAL documents on GitHub. The catalog was published in September 2025, with NIS2 implementation as a legal driver. If one of Europe's most influential baselines now ships as data, others will follow. If none of these apply to you, the signal still matters: regulators and large buyers are tired of reading PDFs, and machine-readable assurance is where procurement is heading. No lock-in OSCAL is an open standard with open-source tooling from NIST and the community. Your compliance data stays portable between GRC platforms, consultants, and assessors. That alone is worth something the next time a tool contract renews. Why adoption stalls If OSCAL is this useful, why do so few organizations use it? In our experience, for three reasons: - The gap between the standard and the system. The schemas are well documented. Mapping your actual architecture, inherited controls, and shared responsibilities into them is not. - The legacy pile. Years of SSPs, spreadsheets, and policy documents do not convert themselves, and a naive conversion just produces machine-readable versions of the same drift. - Ownership. OSCAL sits between security, compliance, engineering, and procurement. Without a clear owner and a narrow first scope, it becomes a side project that never ships. None of these are technical blockers. They are scoping, sequencing, and change-management problems. Where to start 1. Pick one system and one baseline. Not the whole estate. One system that matters, assessed against the framework you already answer to most often. 2. Model the shared components first. Identity, logging, encryption, and your cloud platform carry most controls. Describe them once as component definitions. 3. Build the SSP from references, not prose. Let the system plan inherit from components instead of restating them. 4. Validate in the pipeline. Run schema and content checks on every change, the same way you test code. 5. Connect one evidence source. Feed one automated control check into assessment results, prove the loop works, then expand. How CODACON can help The standard is free. The hard part is the translation: turning your real systems, inherited controls, and existing paperwork into an OSCAL model your teams will actually maintain, then embedding it in how you build and assess. That is where we work. We help organizations scope a first OSCAL implementation, model their shared components, convert what is worth keeping from the legacy pile, and wire validation into their delivery pipeline so the model stays true after we leave. We have already done this end to end for one organization. The engagement is confidential, so we cannot name the client or share their artifacts, but we can walk you through the approach, the pitfalls we hit, and what it would take in your environment. If you are weighing OSCAL, or have started and stalled, let's talk.