사이버 복원력법이 하드웨어에 요구하는 것

두 개의 날짜, 그리고 가까운 쪽이 누락된다

규정 (EU) 2024/2847, 이른바 사이버 복원력법(Cyber Resilience Act, CRA)은 EU 시장에 공급되는 “디지털 요소를 가진 제품”을 다룹니다. 실무적으로는 펌웨어가 들어간 모든 것이고, 소비자 기기와 가정용 헬스케어 기기에서는 오늘 출하되는 거의 전부에 해당합니다.

대부분의 기획 자료에는 날짜가 하나 있습니다. 2027년 12월 11일. 완전 적합이 요구되고, 부적합 제품은 더 이상 시장에 출시할 수 없습니다. 로드맵은 이 날에 맞춰 그려집니다.

먼저 오는 것은 다른 쪽입니다. 2026년 9월 11일, 제14조 신고 의무의 시작일. 이것이 누락되는 이유는 제품 설계 기한이 아니어서 하드웨어 일정표에 오르지 않기 때문입니다.

올라야 합니다. 이유는 아래와 같습니다.

신고 시계는 과거로 거슬러 올라간다

2026년 9월 11일부터, 제조자가 자사 제품에 실제로 악용되고 있는 취약점이 있다는 사실이나 보안에 영향을 주는 중대 사고를 인지하면 단계별 시계가 작동합니다.

단계	인지 시점부터
조기 경보	24시간
기술적 신고	72시간
최종 보고	14일(악용된 취약점) / 1개월(중대 사고)

제출 대상은 ENISA와 해당 국가 CSIRT입니다.

두 번 읽어야 할 대목은 이것입니다. 신고 의무는 이미 EU 시장에 공급된 제품에 적용됩니다. 기한 이전에 출시된 물량도 포함입니다. 부속서 I의 설계 요구사항은 2027년 12월 11일 이후 출시되는 제품에 적용되고, 그 이전 제품에는 실질적 변경이 있을 때만 적용됩니다. 신고 의무에는 그 경계선이 없습니다.

그래서 2026년 9월에 브랜드가 답해야 할 질문은 더 이상 “다음 제품이 적합한가”가 아닙니다. 이렇게 바뀝니다.

2023년에 출하한 기기에서 취약점이 실제로 악용되고 있다. 우리는 24시간 안에 알 수 있는가. 그리고 안에 무엇이 들었는지 문제를 설명할 만큼 알고 있는가.

대부분의 하드웨어 브랜드에게 뒷부분의 정직한 답은 “아니오”입니다. 그것은 보안 문제이기 이전에 생산 기록의 문제입니다.

→ 하우징 설계 결정으로 바뀌는 또 하나의 EU 기한: EU 배터리 규정 2027: 분리형 배터리

지원 기간은 자재명세 결정이다

부속서 I은 최소 5년의 지원 기간 선언을 요구합니다. 예상 수명이 그보다 짧으면 그 수명을 따르고, 종료일은 구매 시점에 구매자가 알고 있어야 합니다. 그 기간 동안 제조자는 취약점을 처리하고 보안 패치를 무상으로 제공합니다.

이 문장은 조달 제약으로 읽으십시오. 실제로 그렇기 때문입니다.

설계에 쓰는 무선 모듈이 공급사 SDK 위에서 돌아가는데 그 SDK가 3년 차부터 보안 패치를 받지 못하면, 그 위에 얹힌 것도 패치할 수 없습니다. 판매 시점에 5년 지원을 선언해 놓고 3년 차에 이행 능력을 잃는 것이며, 원인은 부품 선정 단계의 결정입니다.

그래서 가격, 리드타임, 이원화와 나란히 두 가지 질문이 모듈 검증에 들어갑니다.

• 이 공급사는 이 부품에 몇 년간 보안 패치를 낼 것인가, 서면으로. 그리고 단종 시점에는 어떻게 되는가?
• 우리가 옮겨갈 수 있는 스택을 쓰는 2차 공급처가 있는가, 보드를 다시 설계하지 않고?

두 질문 모두 보통은 자재명세 검토에 없습니다. 그러나 공급 리스크와 같은 대화에 속합니다. 같은 종류의 리스크이기 때문입니다. 부품을 쓸 수 없게 되는 것, 하나는 상업적으로 다른 하나는 법적으로.

→ 부품 등급과 적색이 뜨면 무엇을 뜻하는지: OEM 프로젝트의 부품 공급 리스크 매트릭스

SBOM은 실제로 들어 있는 것을 기술해야 한다

부속서 I 제2부는 널리 쓰이는 기계 판독 형식의 소프트웨어 자재명세를 요구하며, 최소한 최상위 의존성을 포함해야 합니다.

웹 애플리케이션이라면 빌드 도구의 출력입니다. 물리적 제품에서는 조립의 문제가 됩니다. 펌웨어가 전부 자사 것인 경우는 드물기 때문입니다. 전형적인 연결형 소비자 기기에는 이런 것들이 들어 있습니다.

• 이 제품을 위해 작성한 애플리케이션 펌웨어
• 무선 모듈과 함께 들어온 공급사 SDK
• 바이너리로 제공되는 프로토콜 스택(블루투스, 와이파이, 스레드)
• 실시간 운영체제
• 위 중 어느 하나가 끌고 들어온 오픈소스 라이브러리

브랜드가 소유한 것은 보통 첫 항목뿐이고 나머지는 보이지 않습니다. 공장과 그 모듈 공급사를 거쳐 들어왔기 때문입니다. 실효성 있는 SBOM을 구성한다는 것은 공장에 묻고, 공장이 다시 자기 공급사에 묻게 하는 일입니다.

이 요청은 사고가 난 뒤보다 개발 중에 하는 편이 훨씬 쌉니다. 동시에 모듈 제조사가 자기 바이너리의 내용을 알려줄 의사가 있는지도 드러납니다. 설계에 넣기 전에 알아두어야 할 정보입니다.

기본값이 안전할 것, 그리고 업데이트를 받을 수 있을 것

부속서 I의 요구사항 중 둘은 아주 이른 하드웨어 결정으로 내려옵니다.

기본값이 안전할 것은 제품이 안전한 설정으로 출하된다는 뜻입니다. 공통 초기 비밀번호가 없고, 불필요한 서비스나 열린 포트가 없으며, 공격면이 최소화되어 있어야 합니다. 이는 펌웨어 기본값이고, 기본값은 대개 펌웨어를 쓰는 쪽이 정합니다. 그것이 수탁 제조사라면 구현은 그쪽 몫, 규격화는 이쪽 몫입니다.

지원 기간 동안의 무상 보안 업데이트는 제품이 업데이트를 받을 수 있다는 전제 위에 있습니다. 받을 수 있는지는 소프트웨어 결정이 아닙니다.

• 플래시 용량. 안전한 무선 업데이트를 위한 이중 파티션 구성은 펌웨어 소요 공간을 대략 두 배로 만듭니다. 자재명세가 확정된 뒤 알게 되면 메모리 교체나 무선 업데이트 포기 둘 중 하나만 남습니다.
• 연결성. 인터넷 경로가 없는 기기는 현장 작업이나 동반 앱으로만 업데이트됩니다. 둘 다 완료율이 5년 의무가 전제하는 수준에 한참 못 미칩니다.
• 전력. 잔량이 낮을 때 실행되어 기기를 벽돌로 만드는 업데이트는 업데이트하지 않는 것보다 나쁩니다. 그래서 업데이트 로직에는 전력 하한이 필요하고, 그러려면 잔량계가 필요합니다.

셋 다 나중에 싸게 붙이지 못합니다. 셋 다 금형을 파기 전 엔지니어링 심사에서 정해집니다.

→ 이런 제약이 드러나는 심사: 금형을 파기 전의 DFX 리스크 심사

프로젝트에서 실제로 달라지는 것

지금 개발에 들어가 EU로 판매할 제품이라면 세 가지가 달라집니다.

1. 모듈 검증에 패치 제공 기간 항목이 추가됩니다. 공급사의 보안 지원 약속을 서면으로 받고, “공개하지 않습니다”라는 답을 있는 그대로의 답으로 취급하십시오.
2. SBOM이 납품물이 됩니다. 도면·시험 성적서와 나란히 개발 계약에 명시해, 24시간 시계 아래서 재구성하는 대신 제품과 함께 오게 하십시오.
3. 업데이트 가능성을 금형 전에 규격화합니다. 플래시 여유, 파티션 구성, 업데이트 경로는 구상 단계에서는 싸고 하우징이 나온 뒤에는 비쌉니다.

이미 시장에 있는 제품이라면 당면한 질문은 더 좁고 더 급합니다. 안에 무엇이 들었는지 알아낼 수 있는가, 얼마나 빨리?

적용 범위에 관한 참고

이는 공표된 법령에 대한 해석이며 법률 자문이 아닙니다. CRA의 시행 세부는 표준과 지침을 통해 계속 채워지는 중입니다. 이를 토대로 계획을 세우기 전에, 자사 제품군과 대상 시장에 어떻게 적용되는지 자격 있는 법률 자문으로 확인하십시오. 설계의 전제로 삼을 만큼 정해진 것은 방향입니다. 보안 지원은 선언되고 날짜가 붙은 약속이 되었고, 그것을 가능하게도 불가능하게도 만드는 결정은 하드웨어 쪽에서, 그것도 이르게 이루어집니다.

→ 기판 수준의 세부, 회로도에서 SMT 라인까지: 소비자 가전 수탁 제조