Semi E170
SEMI E170 specifies the Secured Foundation of Recipe Management System (SFORMS), a security layer built on top of E42's recipe-management model rather than a replacement for it — E42 defines what a recipe is and how it gets uploaded, verified, and selected; E170 defines who's allowed to do any of that, under what authentication, and with what tamper-evident record. E42 answers "does the equipment have the same recipe the host thinks it uploaded"; E170 answers a question E42's checksum-and-version model was never built to answer: is the party uploading, modifying, or selecting that recipe actually authorized to touch it, and is there a verifiable trail if someone who shouldn't have access tries anyway.
A few things are worth knowing about why recipe management needed a dedicated security standard on top of E42's identity model:
E42 proves a recipe is the recipe the host intended; E170 proves the person who touched it was allowed to. E42's verification is purely structural — a checksum or version tag that confirms the parameter set equipment is about to execute matches what the host uploaded, byte for byte. That check passes just as cleanly whether the upload came from an authorized process engineer following change control or from a disgruntled contractor with stolen credentials who uploaded a byte-perfect but unauthorized substitute recipe. E42 has no concept of "who" at all; it was designed to catch transmission corruption and version drift, not to gate access. SFORMS closes that gap by requiring authenticated, role-based permissions before a recipe operation — upload, edit, delete, or production selection — is allowed to happen in the first place.
SFORMS's tamper-evident audit trail matters precisely because recipe parameters govern process outcomes directly — a wrong etch time or an altered deposition temperature doesn't just produce a bad lot, it can look like a normal lot until yield or reliability failures surface weeks later. Golden recipes are among the most consequential pieces of intellectual property and process control a fab holds; an unauthorized or malicious edit that still passes E42's structural check is arguably more dangerous than an obviously corrupted upload, because nothing about the equipment's own verification flags it. SFORMS requires every recipe operation to carry an authenticated identity and a logged record specifically so that a change can be traced back to who made it and when, not just confirmed to match what was presumably intended.
SFORMS sits in the same family as E170.1's SECS-II protocol extension (the messaging layer that carries SFORMS's authentication and audit data between host and equipment) and alongside the equipment-level security standards this glossary has already covered from other angles — E132's equipment-client authentication and E169's internal information-system security. Where E132 governs which host is allowed to talk to equipment at all and E169 hardens the equipment's own internal computer against compromise, SFORMS is narrower still: it governs authorization and accountability specifically for recipe-management operations, the one category of equipment interaction where an unauthorized-but-structurally-valid change is uniquely hard to detect through any other means.
Read E170 as the standard that closes the gap E42's checksum-and-version model was never built to close: a recipe can be perfectly verified as byte-identical to what the host intended while having been uploaded, edited, or selected by someone with no authorization to touch it at all, and SFORMS is what actually requires an authenticated identity and an auditable trail behind every one of those operations.