통신 경로가 있는 의료기기를 국내에 허가받으려면, 2025년부터는 IEC 62443-4-2 기반의 사이버보안 요구사항 35개를 충족하고 그 검증 자료를 식약처에 제출해야 한다. 그 기준을 담은 문서가 식약처 「의료기기 사이버보안 허가·심사 가이드라인」(안내서-0995-05, 2025.01.10) 이다.
이 글은 그 가이드라인을 규제 실무자와 의료기기 개발자의 관점에서 구조적으로 해설한다. 핵심은 하나다: 국내 의료기기 사이버보안 규제는 이제 산업 자동화·제어 시스템(IACS) 국제 표준인 IEC 62443-4-2의 FR/CR 체계 위에 서 있다. 따라서 이 가이드라인을 읽는 가장 좋은 방법은 IEC 62443의 렌즈로 국내 규제를 매핑하며 읽는 것이다.
1. 문서의 위상: 무엇을, 누구에게 요구하는가
먼저 문서의 정체를 정확히 짚는다.
| 항목 | 내용 |
|---|---|
| 문서 번호 | 안내서-0995-05 |
| 발행처 | 식품의약품안전처 식품의약품안전평가원 의료기기심사부 디지털헬스규제지원과 |
| 발행일 | 2025년 1월 10일 (v05) |
| 표준 근거 | IEC 62443-4-2 / KS X IEC 62443-4-2 |
| 관련 법령 | 의료기기 허가·신고·심사 규정 제29조 제8호; 디지털의료제품법 시행규칙 제19조 |
여기서 반드시 짚어야 할 두 가지가 있다.
첫째, 이 문서는 법적 구속력이 없는 "민원인 안내서"다. 본문에 "∼하여야 한다"는 표현이 반복되지만, 문서 자체는 법이 아니다. 이것을 오해하면 안 된다. 법적 효력이 없다는 것은 "무시해도 된다"는 뜻이 아니라, 이 안내서가 허가·심사 실무에서 사실상의 기준으로 작동한다는 뜻이다. 심사관은 이 안내서를 근거로 자료를 요구하고, 제조자는 이 안내서의 요구사항 체크리스트로 자료를 제출한다. 법적 형식은 안내서지만 실무적 강제력은 상당하다. 특히 후술할 「디지털의료제품법」 체계 안에서 디지털의료기기에는 개정 요구사항이 즉시 적용되므로, 안내서의 "권고"가 실질 요건으로 굳어진다.
둘째, 적용 대상은 "통신 경로가 있는 의료기기 전체"다. 유선이든 무선이든 통신 인터페이스가 하나라도 있으면 대상이 된다.
- 포함 통신 방식: 이더넷, Wi-Fi, 블루투스, USB, RS-232, RF 등
- 포함 임베디드 유형: 펌웨어·PLC 탑재 기기, 의료용 IT 네트워크 연결 기기, 소프트웨어 의료기기(SaMD)
- 제외: 통신 경로가 전혀 없는 폐쇄형 의료기기
즉 USB 포트 하나만 있어도 이 가이드라인의 사정권에 들어온다. 현대 의료기기 중 통신 경로가 완전히 없는 제품은 드물기 때문에, 사실상 대부분의 신규 의료기기가 이 요구사항 체계를 통과해야 한다.
2. 왜 IEC 62443-4-2인가: 규제의 표준 전환
이 가이드라인의 가장 중요한 변화는 표준 근거의 전환이다. 개정 이력을 보면 이 전환의 궤적이 뚜렷하다.
| 버전 | 시기 | 핵심 변화 |
|---|---|---|
| v01 | 2019.11.28 | 최초 제정 |
| v02 | 2022.01.21 | IMDRF 원칙 적용 |
| v03 | 2023.07.13 | 제출자료 명확화 |
| v04 | 2024.11.27 | IEC 62443-4-2로 전환 |
| v05 | 2025.01.10 | 요구사항 시행시기 명확화 |
즉 2024년 말(v04)을 기점으로, 국내 의료기기 사이버보안 규제의 뼈대가 IMDRF(국제의료기기규제자포럼)의 일반 원칙에서 IEC 62443-4-2라는 구체적 기술 표준으로 바뀌었다.
이 전환의 의미는 크다. IMDRF 원칙은 "인증을 해야 한다", "무결성을 보장해야 한다" 같은 원칙 수준의 서술이었다. 반면 IEC 62443-4-2는 IACS(산업 자동화 및 제어 시스템) 컴포넌트에 대한 구체적 기술 보안 요구사항의 카탈로그다. 원자력·발전·제조 같은 중요 인프라의 제어 컴포넌트에 요구되는 보안 통제를, 의료기기라는 또 다른 안전 중대(safety-critical) 임베디드 영역에 이식한 것이다.
이 이식이 자연스러운 이유가 있다. 의료기기와 산업 제어 장치는 보안 관점에서 같은 종(種)이다. 둘 다 (1) 물리 세계에 직접 작용하고, (2) 안전이 최우선이며, (3) 긴 수명과 제한된 연산 자원을 가진 임베디드 시스템이고, (4) 가용성이 기밀성만큼 중요하다. IT 시스템의 보안 프레임워크(예: 일반 정보보안 통제)를 그대로 가져오면 이 특성을 놓친다. IEC 62443은 애초에 이 특성을 위해 만들어진 표준이므로 매핑이 정확하다.
IEC 62443의 FR/CR 체계
IEC 62443-4-2를 이해하려면 그 뼈대인 7개 기초 요구사항(Foundational Requirements, FR) 을 알아야 한다. IEC 62443은 모든 보안 통제를 다음 7개 FR 아래로 분류한다.
| FR | 명칭 | 다루는 것 |
|---|---|---|
| FR 1 | 식별 및 인증 통제 (IAC) | 사용자·기기·프로세스가 누구인지 검증 |
| FR 2 | 사용 통제 (UC) | 인증된 주체에게 무엇을 허용할지 |
| FR 3 | 시스템 무결성 (SI) | 데이터·통신·펌웨어의 변조 방지 |
| FR 4 | 데이터 기밀성 (DC) | 민감 정보 노출 방지 |
| FR 5 | 데이터 흐름 제한 (RDF) | 네트워크 분할·흐름 통제 |
| FR 6 | 이벤트 적시 대응 (TRE) | 사건 탐지·로깅·대응 |
| FR 7 | 자원 가용성 (RA) | DoS 방어·백업·복구 |
각 FR 아래에는 다시 컴포넌트 요구사항(Component Requirement, CR)들이 있다. 식약처 가이드라인의 35개 요구사항은 이 FR/CR 체계를 의료기기 맥락으로 재편성한 것이다. 다만 가이드라인은 FR 5(데이터 흐름 제한)를 독립 카테고리로 두지 않고, 그 취지를 RA(자원 가용성)와 통신 무결성 항목에 흡수했다. 그래서 가이드라인의 카테고리는 6개다.
3. 35개 요구사항의 구조: 6개 카테고리
가이드라인의 핵심인 요구사항 체계는 6개 카테고리, 총 35개 항목으로 구성된다.
| 카테고리 | 약어 | 항목 수 | 대응 IEC 62443 FR |
|---|---|---|---|
| 식별 및 인증 | IA | 8 | FR 1 (IAC) |
| 사용 통제 | UC | 7 | FR 2 (UC) + FR 6 일부 |
| 시스템 무결성 | SI | 11 | FR 3 (SI) |
| 데이터 기밀성 | DC | 3 | FR 4 (DC) |
| 이벤트 적시 대응 | TRE | 1 | FR 6 (TRE) |
| 자원 가용성 | RA | 5 | FR 7 (RA) |
카테고리별 항목 수의 분포 자체가 규제의 무게중심을 드러낸다. 시스템 무결성(SI, 11개)과 식별·인증(IA, 8개)에 절반 이상이 몰려 있다. 이것은 의료기기 보안의 최우선이 "장치가 조작되지 않았음"과 "정당한 주체만 접근함"에 있음을 반영한다. 반면 데이터 기밀성(DC)은 3개로 적은데, 이는 의료기기에서 환자 프라이버시가 중요하지 않아서가 아니라, 가용성과 무결성이 기밀성보다 생명에 더 직결되기 때문이다. 데이터가 유출되는 것보다 장치가 오작동하거나 멈추는 것이 환자에게 더 치명적이다. 이 우선순위는 일반 IT 보안의 CIA 순서와 뒤집혀 있으며, IEC 62443의 철학과 정확히 일치한다.
이제 각 카테고리를 IEC 62443의 관점에서 해설한다.
3.1 식별 및 인증 (IA) — 8개 항목 / FR 1
"누가 접근하는가"를 다루는 카테고리다. FR 1(식별 및 인증 통제)의 의료기기 버전이다.
- IA-01 사용자 식별·인증 — 인가된 사용자(사람·기기·프로세스·서비스)를 식별·인증. 사용자 접근 인터페이스가 없으면 제외.
- IA-02 계정 관리 — 계정 생성·관리·삭제. 공유 계정 사용 시 위험 고려.
- IA-03 식별정보 관리 — 계정별 고유 식별자.
- IA-04 인증정보 관리 — 비밀번호 하드코딩 금지, 기본 계정/비밀번호 변경 기능 필수, 인증정보 암호화 저장.
- IA-05 비밀번호 강도 — 최소 길이·복잡성 정책 설정 기능.
- IA-06 인증정보 피드백 — 비밀번호 입력 시 평문 노출 금지(마스킹).
- IA-07 연속 로그인 실패 제한 — N회 실패 시 잠금/지연, 설정 가능.
- IA-08 시스템 사용 알림 — 로그인 전 무단접근 경고 표시.
여기서 IA-04(비밀번호 하드코딩 금지, 기본 자격증명 변경) 를 특히 주목해야 한다. 임베디드 의료기기의 가장 흔하고 치명적인 취약점이 바로 하드코딩된 자격증명과 변경 불가능한 기본 비밀번호다. 이 항목은 IEC 62443-4-2의 CR 1.5(인증정보 관리)를 그대로 반영하며, 임베디드 기기 보안의 최전선을 규제 요건으로 명문화한 것이다.
3.2 사용 통제 (UC) — 7개 항목 / FR 2 + FR 6 일부
"인증된 주체가 무엇을 할 수 있는가"와 "그 행위를 어떻게 기록하는가"를 다룬다. FR 2(사용 통제)에 감사 로깅(FR 6의 일부)이 결합돼 있다.
- UC-01 권한 부여 — 최소권한 원칙 기반 역할 기반 접근통제(RBAC), 역할별 권한 분리.
- UC-02 모바일 코드 통제 — 모바일 코드 실행 전 진본성 검증, 허용 목록 기반.
- UC-03 세션 잠금 — 일정 시간 비활성 후 자동 잠금·재인증.
- UC-04 감사기록 생성 — 접근통제·요청오류·기기이벤트·백업/복구·설정변경·감사로그 이벤트를 기록. 타임스탬프·출처·카테고리·유형·이벤트ID·결과 포함.
- UC-05 감사 처리 실패 대응 — 감사 저장 용량 초과 시에도 필수 기능 손실 방지.
- UC-06 타임스탬프 — 감사기록에 날짜·시간, NTP 동기화 권고.
- UC-07 부인 방지 — 특정 행동에 사용자 식별 정보 포함.
UC-01의 최소권한(least privilege) 은 이 카테고리 전체를 관통하는 원칙이다. IEC 62443의 개념을 그대로 가져온 것으로, "필요한 최소한의 권한만 부여한다"는 원칙을 역할 기반 접근통제로 구현하도록 요구한다. UC-04~UC-07의 감사 로깅 요구는 사후 대응·포렌식의 기반이며, 특히 UC-06의 타임스탬프 무결성과 UC-07의 부인 방지는 로그가 법적 증거로서 신뢰받기 위한 조건이다.
3.3 시스템 무결성 (SI) — 11개 항목 / FR 3
가장 항목이 많은 카테고리이자, 의료기기 보안의 심장이다. "장치와 데이터가 변조되지 않았음"을 보장한다. FR 3(시스템 무결성)에 대응한다.
- SI-01 통신 무결성 — 표준 암호 프로토콜(예: TLS 1.2/1.3), 전송 중 무결성 보호.
- SI-02 악성코드 보호 — 유입 차단 또는 검증. SaMD는 외부 서비스/앱에도 적용.
- SI-03 보안 기능 검증 — 보안 기능 동작 검증 절차(EICAR 테스트, IDS 규칙 검증 등).
- SI-04 소프트웨어·정보 무결성 점검 — 저장 데이터(설정·펌웨어·구성)에 암호 해시 기반 무결성 점검.
- SI-05 입력값 검증 — 외부 인터페이스 모든 입력의 구문·길이·내용 검증. 범위 이탈·SQL 인젝션·XSS·버퍼 오버플로·악성 패킷 검증 필수.
- SI-06 오류 시 사전 결정된 상태 출력 — 정상 동작 불가 시 사전 정의된 Fail-Safe 상태로 출력.
- SI-07 오류 처리 — 오류 메시지에 공격자 활용 가능 정보(상세 인증 실패 원인 등) 포함 금지.
- SI-08 업데이트 — 필수 기능에 영향 없이 패치.
- SI-09 업데이트 진본성·무결성 검증 — 설치 전 코드 서명·해시 검증, 비정상 서명 파일 차단.
- SI-10 물리적 변조 방지 — 불필요한 외부 인터페이스에 물리적 잠금·보안 나사·캡슐화. SaMD 제외.
- SI-11 부트 프로세스 무결성 — 부팅 시 펌웨어·소프트웨어·설정 무결성 검증(시큐어 부트). SaMD 제외.
이 11개는 IEC 62443-4-2 FR 3의 거의 전체 스펙트럼을 커버한다. 몇 가지 실무적 포인트를 짚는다.
SI-05(입력값 검증) 는 소프트웨어 취약점의 근원을 정면으로 겨냥한다. 버퍼 오버플로·인젝션 계열 취약점은 전부 신뢰할 수 없는 입력을 검증 없이 처리하는 데서 나온다. 이 항목은 개발 단계의 시큐어 코딩을 규제 요건으로 끌어올린다.
SI-06(Fail-Safe) 은 의료기기 특유의 요구다. IT 시스템은 오류 시 멈추면 그만이지만, 물리 세계에 작용하는 의료기기는 "안전한 실패" 라는 개념이 필요하다. 오작동 시 임의 상태가 아니라 사전에 정의된, 환자에게 해가 없는 상태로 수렴해야 한다. 이것은 사이버보안과 기능 안전(functional safety)이 만나는 지점이다.
SI-09(업데이트 서명 검증)와 SI-11(시큐어 부트) 은 공급망·펌웨어 공격 방어의 핵심이다. 서명 검증 없는 업데이트 채널은 악성 펌웨어 주입 경로가 되고, 시큐어 부트 없는 부팅은 부트킷의 온상이 된다. 다만 이 두 항목과 SI-10(물리 변조 방지)은 SaMD에서 제외되는데, SaMD는 특정 하드웨어에 종속되지 않는 순수 소프트웨어이므로 물리적 변조나 부트 체인이라는 개념이 성립하지 않기 때문이다. 이 예외 규정은 요구사항이 기기 유형의 특성을 정확히 반영하도록 설계됐음을 보여 준다.
3.4 데이터 기밀성 (DC) — 3개 항목 / FR 4
민감 정보의 노출을 막는다. 항목 수는 적지만 각각이 밀도 높다.
- DC-01 정보 기밀성 — 저장·전송 정보의 기밀성 보호.
- DC-02 보건의료정보 비식별화 — 환자 식별 가능 정보의 비식별화(가명화). 식별 키는 승인된 사용자만 접근. 개인식별정보를 저장하지 않으면 제외.
- DC-03 안전한 암호화 — 112비트 이상 보안강도의 권고 알고리즘. 비밀번호는 Salt 포함 단방향 해시.
DC-03의 구체성이 눈에 띈다. 가이드라인은 KISA의 「암호 알고리즘 및 키 길이 이용 안내서」를 따라 구체적인 권고 알고리즘 목록을 제시한다.
- 대칭키: SEED, HIGHT, ARIA, LEA, AES (모두 128/192/256비트)
- 해시: SHA-224/256/384/512, SHA3 계열, LSH 계열
- 공개키: RSA-PSS, ECDSA, EC-KCDSA
- 금지에 가까운 것: SHA-1, HAS-160은 80비트 강도로, 메시지인증·키유도·난수생성 용도로만 제한 허용
여기서 국내 표준 암호(SEED, ARIA, LEA, HIGHT, LSH, HAS-160)가 국제 표준(AES, SHA)과 나란히 권고된다는 점이 특징이다. 국내 규제이므로 국산 암호를 포함하되, "112비트 이상 보안강도"라는 정량 기준으로 알고리즘의 강도를 통제한다. DC-02의 비식별화는 「보건의료기본법」의 보건의료정보 개념과 연결되며, 개인정보 보호 규제와의 접점을 이룬다.
3.5 이벤트 적시 대응 (TRE) — 1개 항목 / FR 6
- TRE-01 감사로그 비인가 접근 제한 — 인가된 사용자만 감사로그에 읽기 전용 접근. 감사기록 수정 기능이 없어야 함.
단 하나의 항목이지만 그 무게는 크다. 감사 로그의 무결성은 사후 포렌식의 마지막 보루다. "수정 기능이 없어야 한다"는 요구는 로그가 append-only여야 함을 의미하며, 이것이 지켜지지 않으면 UC-04~UC-07의 모든 감사 로깅이 무의미해진다. 로그를 남겨도 공격자가 지울 수 있으면 로그가 아니다.
3.6 자원 가용성 (RA) — 5개 항목 / FR 7
"장치가 필요할 때 작동함"을 보장한다. 의료기기에서 가용성은 곧 환자 안전이다. FR 7에 대응한다.
- RA-01 DoS 방지 — DoS 중에도 필수 기능 유지. 공용 네트워크 실시간 제어 기기는 DDoS 대응책 수립 의무.
- RA-02 백업 — 백업 기능 필수, 정상 작동에 영향 없이. 백업 내 민감 데이터 암호화.
- RA-03 복구·재구성 — 중단·장애 후 안전한 상태로 복구, 보안 패치 재설치 포함.
- RA-04 네트워크·보안 구성 — 설명서에 구성 인터페이스 명시, 설정 변경 모니터링·통제.
- RA-05 불필요한 기능 비활성화 — 불필요한 포트·프로토콜·서비스 기본 비활성화, 포트 스캔 도구(Zenmap 등)로 검증.
RA-05는 공격 표면 최소화(attack surface reduction)의 원칙을 규제화한 것이다. 쓰지 않는 포트·서비스는 공격 진입점일 뿐이므로 기본적으로 꺼 두어야 한다. "포트 스캔 도구로 검증"이라는 구체적 검증 방법 명시가 인상적이다 — 요구만 하는 것이 아니라 어떻게 확인하는지까지 지정한다. RA-01의 "필수 기능 유지"는 SI-06의 Fail-Safe와 맞물려, 공격을 받아도 최소한의 안전 기능은 죽지 않아야 한다는 의료기기의 안전 철학을 관통한다.
4. 요구사항 적용의 판단 축: 하나도 빠짐없이가 아니다
35개 요구사항을 무조건 전부 적용하는 것이 아니다. 가이드라인은 세 가지 축을 종합해 각 항목의 적용 여부를 판단하도록 한다. 이 "테일러링(tailoring)" 개념은 IEC 62443의 보안 등급(Security Level) 개념을 위험 기반으로 변용한 것이다.
① 위해도(Severity)
| 등급 | 의미 |
|---|---|
| 상 (major) | 침해로 심각한 상해·사망·영구 장애 가능 |
| 중 (moderate) | 일시적·경미한 상해, 의학적 중재 필요 가능 |
| 하 (minor) | 일시적 불편, 가역적 |
② 통신 방법 — 유선(USB, RS-232, LAN 등) vs 무선(Wi-Fi, BT, NFC, RF). 무선은 원격 접근이 쉬워 위험이 높다.
③ 사용 환경
| 구분 | 특성 |
|---|---|
| 병원 내 | 폐쇄망, 제3자 접근 어려움 |
| 병원 외 | 개인용 기기, 제3자 접근 용이 |
| 공용 네트워크 | 인터넷 접속, 시공간 제약 없음 |
이 세 축의 조합으로 위험 수준이 결정되고, 그에 따라 요구사항의 적용 강도가 조정된다. 예를 들어 무선 통신으로 공용 네트워크에 연결되며 위해도가 "상"인 기기는 거의 모든 요구사항을 강하게 적용해야 하는 반면, 병원 폐쇄망 안에서만 쓰이는 유선 저위해도 기기는 일부 항목을 위험관리 근거와 함께 완화·제외할 수 있다.
이 판단이 자의적이지 않도록, 가이드라인은 시험 수행 시 3대 공통 원칙을 못박는다.
- 기본 안전 우선 — 보안 기능이 기기의 기본 안전·필수 성능을 해쳐서는 안 된다.
- 상위 개체 활용 허용 — 기기 자체가 보안 기능을 제공하지 못하면 상위 시스템(병원 IT 네트워크)의 보안 기능을 이용해 설계할 수 있다. 단 적절성·타당성 근거 제출 필수.
- 필수 기능 유지 의무 — 공격으로 일부 기능이 손실돼도 필수 기능은 반드시 유지해야 한다.
두 번째 원칙(상위 개체 활용)은 실무적으로 매우 중요하다. IEC 62443의 "시스템 대 컴포넌트" 관점을 반영한 것으로, 개별 의료기기(컴포넌트)가 모든 보안을 혼자 감당하지 않고 네트워크(시스템) 차원의 보안 통제를 활용할 수 있게 해 준다. 이것은 연산 자원이 제한된 임베디드 의료기기에 현실적인 숨통을 열어 준다.
5. 위험관리 프로세스: 사이버보안을 안전관리에 통합
가이드라인은 사이버보안을 독립된 활동이 아니라 의료기기 위험관리(ISO 14971)의 일부로 통합한다. 6단계 순환 프로세스로 제시된다.
위험분석 → 위험평가 → 위험통제 → 잔류위험 허용성 평가 → 위험관리보고서 → 생산후 정보 관리- 위험분석: 가용성·기밀성·무결성 파괴가 환자에게 미치는 위해요인 식별, 영향·발생 가능성 평가.
- 위험평가: 위험관리 계획서의 수용기준으로 위험감소 필요 여부 결정.
- 위험통제: 통제 방안 선택·구현.
- 잔류위험: 개별·전체 잔류위험의 허용 가능성 평가.
- 위험관리보고서: 전 과정 기록.
- 생산후 관리: 새로운 위험·위험 변화의 지속 모니터링, 고객 의견 반영.
이 구조가 중요한 이유는, 사이버보안이 일회성 인증이 아니라 전 생명주기 활동임을 규정하기 때문이다. 특히 마지막 "생산후 관리(post-market)" 단계는 출시 후 발견되는 새 취약점에 대응하는 지속 의무를 부과한다. 취약점은 매일 새로 발견되므로, 출시 시점의 보안이 영원한 보안이 아니라는 현실을 규제가 인정한 것이다.
6. 허가·심사 제출 자료: 무엇을 내야 하는가
통신 경로가 있는 의료기기를 허가받으려면 다음 자료를 의무 제출해야 한다.
| 자료 | 내용 |
|---|---|
| 사이버보안 요구사항 체크리스트 | 통신 기술·사용 환경·공용 네트워크 사용 여부 + 35개 항목별 적용 여부·입증 방법·문서 번호 |
| 사이버보안 위험관리문서 | 전 생명주기 위해요인 식별 + 위험분석·경감 조치 결과. 요구사항 제외·수정 시 근거 포함 |
| 소프트웨어 검증·유효성 확인 자료 | 위험통제 조치 검증, 시험 절차·결과·재시험 결과 |
| 성능시험성적서 | 식약처 지정 시험검사기관 또는 KISA IoT 보안 인증 등 공인 기관 발급 자료 |
핵심은 체크리스트가 35개 항목 각각에 대해 "적용 여부·입증 방법·문서 번호"를 요구한다는 점이다. 제조자는 각 항목마다 (a) 적용하는가, (b) 적용한다면 어떻게 입증하는가, (c) 근거 문서가 무엇인가를 밝혀야 한다. 어떤 항목을 제외하려면 위험관리문서로 그 제외의 타당성을 입증해야 한다. 즉 "이 항목은 우리 기기에 해당 없음"이라고 그냥 넘길 수 없고, 왜 해당 없는지를 문서로 논증해야 한다.
또한 성능시험성적서로 KISA IoT 보안 인증이 인정된다는 점은 실무적으로 중요하다. 별도의 사이버보안 성능 시험을 처음부터 받는 대신, KISA의 IoT 보안 인증을 활용할 수 있는 경로가 열려 있다.
변경 시 재허가: 통신 방법·OS·통신 목적을 변경·추가하면 변경허가·인증·신고가 필요하다. 단 변경이 사이버보안에 영향이 없음을 입증하는 자료(설계 문서 등)를 제출하면 추가 자료가 면제된다.
7. 개정 전후 매핑과 전환 일정
IEC 62443-4-2 전환에 따라, 개정 전(IMDRF 2020 기반, v01~v04 일부)과 개정 후(v05) 요구사항 사이의 대응 관계가 별첨으로 제공된다. 주요 매핑은 다음과 같다.
| 개정 전 항목 | 개정 후 매핑 |
|---|---|
| 통신 구성 | RA-04, RA-05 |
| 접근통제 및 인증 | UC-01~UC-03, SI-01 |
| 데이터 전송·저장 기밀성·무결성 | DC-01~DC-03 |
| 시스템 로그 기록 | UC-04~UC-07, TRE-01 |
| 주요 파일 무결성 검증 | SI-03, SI-04, SI-11 |
| 사용자 인증 관리 | IA-01~IA-07, UC-01 |
| 펌웨어·SW 업데이트 인가 | SI-08 |
| 업데이트 무결성 보장 | SI-09 |
| DDoS 공격 방어 | RA-01 |
이 매핑 표는 기존에 IMDRF 기반으로 허가받았거나 준비 중인 제조자가 새 체계로 갈아타는 다리 역할을 한다. 예전에 "사용자 인증 관리"라는 하나의 항목으로 다루던 것이, 이제 IA-01~IA-07의 세분화된 요구사항으로 펼쳐졌음을 보여 준다. 전환이 곧 요구사항의 정밀화임을 알 수 있다.
전환 일정은 다음과 같다.
- 2025.6.30까지: 개정 전(IMDRF 기반) 요구사항을 한시적으로 허용.
- 2025.1.24 이후: 「디지털의료제품법」에 따른 디지털의료기기는 즉시 개정 요구사항(v05) 적용.
즉 일반 의료기기에는 2025년 상반기까지 유예가 있었지만, 디지털의료기기는 2025년 초부터 새 체계가 즉시 적용됐다. 디지털의료기기가 규제의 최전선에 놓인 것이다.
AI 보안의 추가 축: 가이드라인은 「디지털의료제품법」 제14조와 「디지털의료기기 전자적 침해행위 보안지침」이 요구하는 인공지능 보안을, 표 2의 요구사항에 추가하거나 적절한 항목을 선별해 추가 검증하도록 언급한다. 다만 이 부분은 별도 기준이 아직 확정되지 않았으므로 최신 고시를 확인해야 한다. AI가 탑재된 의료기기(AI/ML 기반 진단 소프트웨어 등)에 대한 보안 요구사항은 이 가이드라인 위에 별도로 쌓일 것임을 예고하는 대목이다.
8. 정리: 이 가이드라인을 어떻게 읽을 것인가
개발자와 규제 실무자를 위해 핵심을 압축한다.
첫째, 이것은 IEC 62443-4-2의 의료기기 프로파일이다. 국제 산업 제어 보안 표준의 FR/CR 체계를 의료기기 맥락으로 이식한 것이므로, IEC 62443에 익숙하다면 매핑으로 빠르게 이해할 수 있다. 반대로 이 가이드라인을 공부하면 IEC 62443의 핵심 골격을 함께 익히게 된다.
둘째, 무게중심은 무결성(SI 11개)과 인증(IA 8개)에 있다. 데이터 유출보다 장치 변조와 무단 접근이 환자 안전에 더 직결되기 때문이다. 기밀성보다 가용성·무결성이 우선하는 이 뒤집힌 CIA 순서가 의료기기 보안의 정체성이다.
셋째, 35개를 무조건 다 하는 것이 아니라 위험 기반으로 테일러링한다. 위해도·통신 방법·사용 환경의 세 축으로 적용 강도를 조정하되, 제외하는 항목마다 위험관리문서로 근거를 논증해야 한다. "해당 없음"도 문서로 증명하는 것이 이 규제의 핵심 부담이다.
넷째, 사이버보안은 일회성이 아니라 생명주기 활동이다. 출시 전 허가뿐 아니라 생산후 관리로 지속 대응 의무가 부과된다. 그리고 AI 탑재 기기에는 추가 검증 축이 예고돼 있다.
다섯째, 문서의 법적 형식은 "안내서"지만 실무적 강제력은 상당하다. 특히 디지털의료기기에는 2025.1.24부터 개정 요구사항이 즉시 적용되므로, 신규 의료기기 개발자는 이 35개 요구사항을 설계 초기부터 반영해야 한다. 사이버보안을 나중에 붙이는 볼트온으로 접근하면 허가 단계에서 막힌다 — IEC 62443-4-1(안전한 제품 개발 생명주기)이 요구하듯, 보안은 설계의 처음부터 들어가 있어야 한다.
의료기기가 점점 더 연결되고, 소프트웨어화되고, AI를 탑재하는 방향으로 진화하는 한, 이 가이드라인이 정의하는 사이버보안 요건은 확대될 것이다. 안내서-0995-05는 그 진화의 현재 좌표이자, 국내 의료기기 보안 규제가 국제 표준 IEC 62443의 궤도에 올라섰음을 알리는 이정표다.
