정보관리기술사 학습 노트
← 목록으로
보안·개인정보
#CRA#Regulation (EU) 2024/2847#디지털 요소 제품#제품 보안#SBOM#취약점 관리#보안 업데이트#적합성 평가#ENISA
최종 업데이트 · 2026-09-29

EU 사이버복원력법(CRA) 기반 디지털 제품 보안 설계와 취약점 대응

1. 개요

가. 정의와 등장 배경

사이버복원력법(Cyber Resilience Act, CRA)은 EU 시장에 제공되는 디지털 요소 제품의 설계·개발·생산 단계부터 취약점 처리와 보안 업데이트까지 제조자의 사이버보안 의무를 규정한 Regulation (EU) 2024/2847이다.

네트워크 연결 제품은 운영체제와 애플리케이션뿐 아니라 센서, 라우터, 스마트 가전, 산업용 제어기, 개발 도구까지 확장되었다. 제품 하나의 취약점은 제품 공급자의 경계를 넘어 사용자 단말, 기업 네트워크, 클라우드와 공급망으로 침해 경로를 제공할 수 있다. 기존에는 보안 업데이트 기간과 취약점 처리 절차가 제조자별로 달라, 제품 구매자가 지원 종료와 잔여 위험을 일관되게 평가하기 어려웠다.

CRA는 시장에 출시하기 전에 보안 요구사항을 만족하는 것과 출시 후 취약점을 관리하는 것을 한 체계로 묶는다. 제조자는 제품을 안전하게 설계할 뿐 아니라, 지원 기간을 정하고 취약점 신고를 받아 처리하며, 보안 업데이트를 배포해야 한다. 그러므로 CRA는 단순 CE 마킹이나 제품 인증 규정이 아니라 제품의 보안 생애주기와 제조자 책임을 재구성하는 수평 규정이다.

나. 적용 대상과 목적

CRA는 의도된 용도 또는 합리적으로 예견되는 사용에 장치나 네트워크와의 직접·간접 데이터 연결이 포함되는 제품에 적용된다. 대상에는 소프트웨어·하드웨어 제품, 제조자가 책임지는 원격 데이터 처리 기능, 별도로 시장에 제공되는 소프트웨어·하드웨어 구성요소가 포함된다. 유상 판매뿐 아니라 상업 활동의 일환으로 무상 제공되는 제품도 적용될 수 있으므로, 무료 앱이나 오픈소스라는 이유만으로 자동 면제되는 것은 아니다.

의료기기, 체외진단 의료기기, 차량 형식승인 체계의 제품, 민간항공 인증 제품, 해양 장비 등은 CRA의 적용 제외 또는 별도 규율을 받는다. 국가안보·국방 목적에만 개발되거나 기밀정보 처리 전용인 제품에도 예외가 있으며, 다른 EU 법률이 같은 위험을 충분히 다루는 경우 적용 조정이 가능하다. 따라서 대상 여부는 제품 이름이나 산업만으로 결정하지 말고 기능, 연결성, 판매 방식, 제조자 책임, 다른 법률의 적용 범위를 함께 분석한다.

CRA의 정책 목적은 시장에 유통되는 제품의 기본 보안 수준을 높이고, 이용자가 보안 상태와 지원 종료 시점을 이해하도록 하는 것이다. 제품 보안은 출시 전 시험으로 끝나지 않으며, 구성요소의 새 취약점과 공격기법이 발견되는 운영 기간 내내 유지되어야 한다. 제조자·수입자·유통자·오픈소스 소프트웨어 스튜어드의 역할을 구분하면 제품 생태계의 책임 공백을 줄일 수 있다.

2. CRA의 규제 구조와 제품 생애주기

CRA 이행은 법 조항을 담당 부서에 배분하는 작업이 아니라, 제품의 보안 위험을 요구사항·설계 결정·시험 결과·업데이트로 추적하는 생애주기 관리다. 제조자는 제품의 의도된 용도와 합리적으로 예견되는 사용을 기준으로 사이버보안 위험평가를 수행하고, 그 결과를 설계와 기술문서에 반영한다. 출시 후에는 취약점 모니터링, 대응, 사용자 공지, 보안 업데이트와 지원 종료까지 같은 위험평가를 지속 갱신한다.

flowchart LR
  A["시장·제품 범위 판정"] --> B["사이버보안 위험평가"]
  B --> C["보안 요구사항·설계 기준"]
  C --> D["개발·구성요소 점검·시험"]
  D --> E["적합성 평가·기술문서·CE"]
  E --> F["시장 출시·사용자 정보"]
  F --> G["취약점 접수·분석·조정 공개"]
  G --> H["보안 수정·안전한 업데이트"]
  H --> I["지원 종료·제품 폐기 안내"]
  G --> B

이 흐름에서 위험평가는 설계 단계에 한 번 작성하고 보관하는 서류가 아니다. 제품 기능, 외부 인터페이스, 사용 환경, 저장 데이터, 원격 관리 기능이 바뀌거나 새로운 취약점이 나타나면 위험과 통제를 재검토한다. 예를 들어 영상 카메라에 원격 계정 복구 기능을 추가하면 인증·권한 상승·개인정보 노출 위험을 다시 분석하고 시험 범위를 조정해야 한다.

가. 제조자와 공급망 행위자의 책임

CRA의 핵심 의무는 제품을 자신의 이름이나 상표로 시장에 제공하는 제조자에게 부과된다. 실제 설계와 생산을 외주화했더라도 제품을 자기 브랜드로 출시하는 기업은 제조자 책임을 피할 수 없으며, 제품의 보안 위험평가와 적합성 입증을 통제해야 한다. 제조자는 제품의 기술문서, EU 적합성 선언, 사용자 안내, 보안 지원 기간 및 취약점 처리 체계를 준비한다.

수입자는 EU 시장에 제품을 처음 반입하기 전에 제조자가 적합성 평가를 완료하고 필요한 문서·CE 표시·연락처 정보를 갖추었는지 확인한다. 제품이 규정에 부합하지 않거나 중대한 위험을 제기한다고 의심되면 시정조치가 이루어질 때까지 유통을 제한하고 관할 기관에 협력한다. 유통자는 보관·운송 조건이 제품의 보안 준수 상태를 훼손하지 않도록 하고, 제품 식별·연락 정보와 필요한 안내가 제공되는지 점검한다.

조직은 단순히 조달 계약서에 “CRA 준수” 문구를 넣는 데 그치지 말아야 한다. 공급자의 적합성 선언, 제품 버전, 지원 종료일, 취약점 공개 창구, 업데이트 배포 정책, 하위 구성요소 정보를 조달 데이터에 연결해야 한다. 이 정보가 없으면 제품을 도입한 조직은 취약점이 발견되었을 때 영향받는 장비와 지원 가능 기간을 빠르게 식별하기 어렵다.

나. 필수 사이버보안 요구사항

부속서 I의 필수 요구사항은 제품의 위험에 비례해 적용되며, 제조자는 제품을 기본적으로 안전하게 설계·개발·생산해야 한다. 시장 출시 시 알려진 악용 가능 취약점이 없어야 하고, 보안 수준이 적절한 기본 설정, 접근통제, 데이터 기밀성·무결성·가용성 보호를 제공해야 한다. 제품은 공격 표면을 줄이고 보안 관련 활동을 기록하며, 필요한 경우 사용자가 데이터를 안전하게 삭제하거나 제품을 초기화할 수 있도록 해야 한다.

제품의 기능과 위협 모델에 따라 요구 통제는 달라진다. 네트워크 카메라는 강한 기본 인증과 안전한 원격 업데이트가 중요하지만, 암호키 저장 장치는 변조 저항성, 키 수명주기, 안전한 키 폐기가 더 핵심이 될 수 있다. 제조자는 모든 제품에 동일한 통제 목록을 기계적으로 적용하기보다 위험평가에서 요구사항의 적용 여부와 예외 사유를 설명해야 한다.

취약점 처리는 보안 신고 접수부터 확인, 우선순위 지정, 수정, 사용자 통지, 업데이트 배포, 사후 검증을 포함한다. 조정된 취약점 공개(CVD) 정책과 신고 채널을 운영하고, 외부 연구자나 고객이 취약점을 안전하게 알릴 수 있도록 해야 한다. 제품에 포함된 제3자 구성요소의 취약점도 최종 제품 제조자의 공급망 위험으로 다뤄야 하며, 오픈소스 구성요소라는 이유로 관리 책임을 외부에 전가할 수 없다.

SBOM(소프트웨어 자재명세서)은 구성요소와 종속 관계를 파악하는 기초 자료다. CRA의 취약점 처리 요구는 최소한 최상위 수준 종속성을 포함하는 SBOM 준비를 명시하지만, SBOM 하나만으로 안전성을 보증하지는 않는다. 구성요소 버전, 취약점 영향, 실제 제품 내 도달 가능성, 완화 조치, 수정 배포 상태를 지속적으로 연결해야 SBOM이 대응 데이터로 기능한다.

다. 지원 기간과 보안 업데이트

제조자는 제품의 성격, 용도, 예상 사용 기간, 이용자의 합리적 기대 등을 고려해 취약점 처리 지원 기간을 정하고 문서화한다. 지원 기간은 원칙적으로 최소 5년이며, 제품이 5년보다 짧게 사용될 것으로 예상되는 경우에는 합리적으로 예상되는 사용 기간을 기준으로 정할 수 있다. 제조자는 종료 시점을 적어도 월과 연도 단위로 명확히 표시하고, 기술적으로 가능한 경우 지원 종료를 사용자에게 알려야 한다.

지원 기간 동안 제조자는 취약점을 지체 없이 처리하고 필요한 보안 업데이트를 제공해야 한다. 업데이트는 안전하게 배포하고, 기술적으로 가능한 경우 기능 업데이트와 보안 업데이트를 분리해 사용자가 위험 수정 내용을 식별하도록 한다. 보안 업데이트는 별도 합의가 없는 한 무상 제공되며, 사용자가 조치를 취해야 하는 경우 업데이트 안내와 필요한 정보를 함께 제공한다.

각 보안 업데이트는 발행 후 최소 10년 또는 남은 지원 기간 중 더 긴 기간 동안 이용 가능해야 한다. 이는 단순히 업데이트 파일을 웹사이트에 계속 올려두는 것이 아니라, 제품 식별·무결성·배포 경로와 지원 종료 정책을 관리해야 한다는 뜻이다. 예를 들어 7년 지원 제품의 보안 수정본은 발행 후 10년 동안 접근 가능하게 보관해야 하며, 장기 사용 제품은 해당 제품의 지원 기간을 고려해야 한다.

제품의 수명 주기가 제조자의 지원 기간보다 길어질 수 있으므로, 구매자는 보안 지원이 끝난 장비를 격리·교체할 계획을 마련해야 한다. 제조자는 지원 종료 후 제품을 어떻게 사용해야 하는지, 위험을 줄일 수 있는 대안이 무엇인지 투명하게 안내하는 것이 바람직하다. 지원 기간은 마케팅 문구가 아니라 조달·자산관리·취약점 대응·예산 계획에 반영되는 운영 기준이다.

3. 취약점·중대 사고 보고 및 적합성 절차

CRA는 제조자가 적극적으로 악용되는 취약점이나 제품 보안에 영향을 주는 중대한 사고를 알게 된 경우 이를 보고하도록 한다. 보고 체계는 내부 보안관제, 제품 개발 조직, 고객지원, 공급자 연락망을 연결해 “인지 시점”을 놓치지 않는 것이 중요하다. 보고 가능 사건은 기업 내부의 전사 침해사고와 같지 않으며, 해당 제품의 보안 기능과 사용자 네트워크에 미치는 영향을 기준으로 판정한다.

sequenceDiagram
  participant R as 연구자·고객·관제
  participant M as 제조자 보안대응팀
  participant E as ENISA 단일보고 플랫폼
  participant C as 지정 조정 CSIRT
  participant U as 영향받는 사용자
  R->>M: 취약점 또는 제품 사고 신고
  M->>M: 확인·영향분석·인지시각 기록
  M->>E: 24시간 이내 조기 경고
  E->>C: 관할 CSIRT와 정보 공유
  M->>E: 72시간 이내 상세 통지
  M->>U: 완화·수정·사용자 안내
  M->>M: 수정본 준비·배포·검증
  M->>E: 취약점은 수정 가능 후 14일 이내 최종보고
  M->>E: 중대 사고는 상세 통지 후 1개월 이내 최종보고

가. 24시간·72시간·최종 보고

적극적으로 악용되는 취약점에 대해 제조자는 인지한 뒤 부당한 지체 없이, 늦어도 24시간 이내에 조기 경고를 제출한다. 일반적으로 72시간 이내에는 제품·취약점·악용 상황에 관한 이용 가능한 정보와 완화 또는 시정 조치를 담은 본 통지를 제출한다. 수정 또는 완화 조치가 이용 가능해진 날부터 늦어도 14일 이내에는 최종 보고를 제출한다.

제품 보안에 영향을 미치는 중대한 사고도 24시간 조기 경고와 72시간 이내 통지가 요구된다. 사고 최종 보고는 본 통지를 제출한 날부터 1개월 이내에 한다. 조기 단계에서 사실이 모두 확인되지 않았다면 불확실성을 명시하고, 조사 결과에 따라 정보를 갱신하는 절차를 둔다.

제조자는 ENISA가 운영하는 단일보고 플랫폼을 통해 지정 조정 CSIRT와 ENISA에 통지한다. 보고 자동화는 인지 시각, 제품 목록, EU 내 판매 국가, 사건 분류, 사용자 영향, 완화 조치와 책임자 정보를 기록해 기한 계산과 증거 보존을 지원한다. 한편 초기 보고를 이유로 취약점 세부정보가 널리 노출되지 않도록 정보 민감도와 조정 공개 시점을 함께 관리해야 한다.

나. 적합성 평가와 제품 등급

CRA는 제품의 중요도와 사이버보안 위험에 따라 적합성 평가의 강도를 달리한다. 일반 제품은 내부 생산 관리, EU 형식검사 후 생산 적합성, 전체 품질보증 또는 이용 가능한 EU 사이버보안 인증 경로를 선택할 수 있다. 중요 제품 Class I은 적용 가능한 조화표준·공통 규격·인증 제도가 없거나 일부만 적용되는 경우 제3자 적합성 평가 절차가 요구될 수 있다.

중요 제품 Class II는 더 높은 위험을 반영해 형식검사와 생산 통제, 전체 품질보증 또는 충분한 보증 수준의 유럽 사이버보안 인증을 통해 평가한다. 중요 제품에는 운영체제, 네트워크 관리·보안 도구, 브라우저, 암호·인증 제품 등 광범위한 기술 제품군이 포함될 수 있다. Class II 예시는 하이퍼바이저·컨테이너 런타임, 방화벽·침입 탐지·방지 시스템, 변조 방지 마이크로프로세서·마이크로컨트롤러 등이다.

부속서 IV의 중요 핵심 제품은 EU 사이버보안 인증제도 또는 규정이 정한 Class II 평가 절차를 적용한다. 따라서 제품팀은 기능을 구현한 뒤에 등급을 확인하는 것이 아니라, 초기 제품 분류 단계에서 대상 부속서·평가 모듈·시험기관 필요성을 판단해야 한다. 분류를 잘못하면 출시 일정과 시험 예산이 지연되고, 적합성 선언의 근거가 불충분해질 수 있다.

구분 CRA 관점 실무 산출물
제품 분류 일반·중요 Class I·중요 Class II·중요 핵심 제품 판정 제품 범위·등급 근거
위험평가 용도·연결성·위협·영향에 비례한 위험 분석 위험평가서·통제 추적표
적합성 평가 등급·표준 적용 여부에 맞는 내부·제3자 평가 시험성적·인증·적합성 선언
취약점 운영 신고·분석·수정·보고·공개를 지원 기간 동안 수행 CVD 정책·사고 기록·업데이트
사용자 정보 보안 기능·지원 기간·안전한 사용을 이해 가능하게 안내 제품 라벨·설명서·지원 종료 공지

표는 문서 묶음의 이름이 아니라 통제 간 추적성을 보여주는 요약이다. 예를 들어 제품 등급이 Class II로 판정되었다면, 해당 판정이 어떤 부속서 기준에 근거하는지, 어떤 적합성 모듈을 적용하는지, 설계 요구사항과 시험 결과가 어떻게 연결되는지 설명할 수 있어야 한다. 기술문서는 규제기관에 제출할 때만 만드는 산출물이 아니라 제품팀의 설계·검증 의사결정 기록이다.

4. 타 규범과의 비교 및 산업 적용 사례

CRA는 제품 자체의 보안과 제조자의 생애주기 책임을 중심으로 한다. NIS2는 중요·필수 조직의 사이버 위험관리와 사고 대응을 다루고, GDPR은 개인정보 처리자의 데이터 보호 의무를 다루며, EU AI Act는 AI 시스템의 위험과 투명성·거버넌스를 규율한다. 하나의 제품이나 기업이 여러 규범의 적용을 동시에 받을 수 있으므로, 규정별 문서만 별도 구축하기보다 공통 위험·자산·사고·증적 데이터에 요구사항을 매핑해야 한다.

비교축 CRA NIS2 GDPR
중심 대상 디지털 요소 제품과 제조자 필수·중요 조직 및 공급망 개인정보 처리와 정보주체 권리
주된 통제 제품 설계·취약점 처리·업데이트·적합성 조직 위험관리·운영 보안·사고 대응 적법성·최소화·보안·침해 통지
주요 관점 제품이 시장에 나오기 전후의 생애주기 조직 서비스의 연속성과 사이버 위험 개인 데이터 처리의 권리·책임
연결 지점 제품 취약점이 고객 조직 침해로 번질 수 있음 제품 공급망과 조직의 의존성 관리 제품이 개인정보를 처리하면 함께 적용

첫 번째 사례는 유럽에 연결형 홈 카메라를 판매하는 제조자다. 제품 분류 시 카메라, 앱, 원격 저장 기능, 기본 비밀번호, 업데이트 서버와 구성요소를 함께 식별한다. 위험평가에서 탈취된 계정으로 영상에 접근하는 경로를 찾아 기본 계정 제거, 안전한 페어링, 관리자 접근통제, 암호화, 업데이트 무결성 검증을 설계한다.

제품 출시 후 영상 앱에 포함된 라이브러리에서 적극 악용 취약점이 발견되면, 제조자는 SBOM과 제품 버전 정보를 이용해 영향 장비를 식별한다. 인지시각을 기록하고 24시간 조기 경고, 72시간 본 통지, 수정 조치 이용 후 14일 이내 최종보고를 준비한다. 사용자 공지와 안전한 업데이트 배포를 병행하고, 지원 종료 제품에도 보고 의무가 미치는 상황을 고려해 자산과 고객 연락 경로를 유지한다.

두 번째 사례는 스마트 미터 게이트웨이 제조자가 보안 업데이트 기간을 2년으로만 정하려는 경우다. 전력 설비에 장착된 장비가 통상 10년 이상 사용될 것으로 예측된다면, 짧은 지원 기간은 제품의 성격과 이용자의 합리적 기대에 맞지 않을 수 있다. 제조자는 예상 사용 기간, 계약·규제 요건, 구성요소 지원 상태를 문서화하고, 업데이트 비용·키 관리·현장 교체 계획을 제품 사업모델에 포함해야 한다.

세 번째 사례는 기반 오픈소스 라이브러리를 제품에 통합하는 제조자와 그 라이브러리를 지속 지원하는 비영리 재단이다. 제조자는 자사 제품의 최종 적합성과 위험 평가 책임을 유지하면서 재단의 보안 정책, 취약점 접수 절차, 구성요소 버전과 수정 릴리스를 관리한다. 재단이 CRA상 오픈소스 소프트웨어 스튜어드에 해당한다면 자체 정책·개발자 지원·취약점 처리 책임이 발생할 수 있지만, 그것이 제조자의 의무를 대체하지는 않는다.

5. 심화: 2026년 단계 적용과 제품 공급망의 실행 과제

CRA는 2024년 12월 10일 발효되었고, 일반적인 제품 의무는 2027년 12월 11일부터 적용된다. 적합성 평가기관 통보 관련 Chapter IV는 2026년 6월 11일부터 적용되며, 제조자의 취약점·중대 사고 보고 의무는 2026년 9월 11일부터 이미 적용되고 있다. 특히 보고 의무는 2027년 12월 이전 시장에 출시된 적용 대상 제품에도 미치므로, 기존 제품 재고와 고객 지원 체계를 지금부터 포함해야 한다.

단계 적용은 조직의 준비 순서를 바꾼다. 첫째, 제품 포트폴리오를 분류하고 제조자·수입자 역할 및 EU 내 유통 경로를 정리한다. 둘째, 취약점 신고·인지 에스컬레이션·ENISA 단일보고 플랫폼 제출 절차를 시행해 24시간 기한을 보장한다. 셋째, 2027년 전면 적용에 앞서 위험평가, 기술문서, 지원 기간, 업데이트 체계, 적합성 평가를 제품 개발 프로세스에 반영한다.

클라우드 서비스는 CRA 제품 범위 여부를 기능별로 검토해야 한다. 원격 데이터 처리가 제조자에 의해 설계·개발되거나 제조자의 책임 아래 제공되고, 그 기능이 없으면 제품 기능 일부가 수행 불가능한 경우 제품의 원격 처리 구성요소로 포섭될 수 있다. 반대로 독립형 일반 클라우드 서비스가 자동으로 CRA 제품이 된다고 단정할 수는 없으며, 구체적인 제품-서비스 관계와 규정상 정의를 확인해야 한다.

오픈소스 생태계에서는 일반 기여자와 지속 지원을 조직적으로 제공하는 스튜어드의 역할을 구별해야 한다. CRA는 무상 오픈소스 제품의 모든 자발적 기여자를 제조자로 취급하지 않으면서도, 상업 활동에 투입되는 제품의 지속성을 조직적으로 뒷받침하는 스튜어드에게 별도 정책·협력 책임을 부과한다. 최종 제품 제조자는 외부 코드의 출처와 보안 상태를 실사하고, 취약점 보고와 수정 협력 경로를 공급망 계약 및 커뮤니티 운영 방식에 맞게 설계한다.

6. 고려사항 및 시사점

가. 제품 보안을 요구사항 추적성으로 구현

보안 원칙을 선언하는 것만으로 적합성을 입증하기 어렵다. 위험 시나리오, 요구사항, 설계 통제, 시험 케이스, 미해결 결함, 출시 승인 사이의 추적성을 마련하고 각 결정의 책임자를 명확히 한다.

나. 취약점 대응을 운영 서비스로 설계

24시간·72시간 보고 기한은 제품 조직과 보안 조직이 분리되어 있으면 놓치기 쉽다. 전사 관제만이 아니라 제품 보안팀, 고객지원, 법무, 공급자 관리, EU 담당자 간 상시 연락망과 대체자를 정하고 모의훈련으로 실제 제출 시간을 측정한다.

다. SBOM과 제품 식별의 품질 확보

부정확하거나 갱신되지 않은 SBOM은 영향받는 제품을 잘못 분류해 수정 배포를 지연시킨다. 릴리스·고객·구성요소 버전을 연결하고, 취약점 스캐너의 일치 결과를 도달 가능성·악용 가능성·완화 상태와 함께 판단한다.

라. 지원 기간과 사업모델의 정합성

장기 지원은 보안 인력, 서명키, 빌드 재현성, 배포 인프라 및 현장 업데이트 비용을 발생시킨다. 제조자는 단기 판매가격만으로 경쟁하지 말고 지원 기간을 제품 원가와 서비스 계약에 반영하며, 부품 단종·클라우드 종료·키 회전까지 고려한 운영 재원을 마련한다.

마. 적합성 등급 조기 판정

제품팀이 마지막 단계에서 중요 제품 등급이나 제3자 평가 필요성을 발견하면 설계 변경과 출시 지연이 발생할 수 있다. 제품 기획·아키텍처 승인 단계에서 제품 분류, 적용 표준, 평가기관, 기술문서 책임을 검토하고 새로운 기능·원격 처리 변경 때 판정을 다시 수행한다.

바. 타 규범과 공통 통제 재사용

CRA, NIS2, GDPR 및 AI 규범은 대상과 법적 의무가 다르지만 위험평가·자산목록·사고 대응·접근통제·증적관리에서 겹치는 통제가 있다. 공통 통제 라이브러리를 두되, 제품 적합성 책임과 조직 운영 책임, 개인정보 침해 통지를 혼동하지 않도록 규범별 적용성·책임자·기한을 분리 매핑한다.

사. 한국 기업의 EU 시장 진출 준비

EU에 디지털 요소 제품을 공급하는 한국 제조사도 EU 시장 출시와 역할에 따라 CRA 요구의 영향을 받을 수 있다. 수입자·유통자·고객이 요구하는 제품 문서, 지원 기간, 취약점 신고 창구, 업데이트 정책과 연락 책임자를 계약·제품 포트폴리오 수준에서 관리해야 한다. 기술사는 이를 법무 검토에 한정하지 않고 DevSecOps, SBOM, PSIRT, 제품 수명주기 관리, 조달·고객 지원을 통합하는 실행 로드맵으로 제시한다.

참고자료

한 줄 요약: CRA는 디지털 제품을 안전하게 설계하고 취약점을 지원 기간 내 처리하며, 2026년부터 보고 의무를 이행하고 2027년 전면 적용에 대비하도록 제조자 책임을 제품 생애주기에 내재화하는 EU 규정이다.